I read a JSON from a file and I'm using SwiftyJSON for that.
My code is aware of the structure and will never access any wrong keys. However it will access some keys a big number of times (I hold there my app strings).
My question is should I convert my data structure to an array when I read the JSON or will SwiftyJSON object be good enough?
Ideally you'll have a struct that can serialize/deserialize to/from JSON or [String:AnyObject]
If your question is primarily driven by performance considerations I'd say that it is good enough until proven that it is not.
Related
I've inherited some code which makes calls to a web API, and get's a deeply nested (up to eight levels) response.
I've written some code to flatten the structure so that it can be written to .csv files, and a SQL database, for people to consume more easily.
What I'd really like to do though is keep a version of the original response, so that there's a reference of the original structure if I ever want/need it.
I understand that HDF5 is primarily meant to store numerical data. Is there any reason not to use it to dump JSON blobs? It seems a lot easier than setting up a NoSQL database.
It should be fine. It sounds like you'd be storing each JSON response as a HDF5 variable length string. Which is fine, it's just a string to the library.
Do you plan to store each response as a separate dataset? That may be inefficient if you are talking about >1000's of responses.
Alternatively, you can create a 1-d extensible dataset, and just append to it with each response.
Decided it was easier to set up a Mongo database.
Is there a proper way to store generic JSON in MongoDB? With 'generic' I mean any JSON, including hashes with keys that are restricted in MongoDB documents.
For example, we want to store JSON schemas which use the key $ref, which is not allowed in a MongoDB document. This means that a JSON schema as such cannot be stored as a MongoDB document.
Is there a smart way around this? The only options I've come up with is to do back-and-forth deep key replacements or to store it as JSON text.
We're using Morphia, so the solution should be compatible with it.
The solutions you have already thought of are probably the best. Store the schemas as JSON strings then parse them back to JSON on retrieval.
I encountered many troubles of dealing with serializing/deserializing Scala data types to/from JSON objects and then store them to/from MongoDB in BSON form.
1st question: why Play Framework uses JSON why MongoDb uses BSON.
2nd question: If I am not wrong, Javascript does not have readers and writers for serializing/deserializing BSON from MongoDB. How can this happen? Javascript can seamlessly handle JSON, but for BSON I expect it needs some sort of readers and writers.
3rd question: (I read somewhere) why Salat and ReactiveMongo uses different mechanisms to talk to MongoDB.
JSON is a widely used format for transfer data in this days. So pretty good to have it "from the box" in the web framework. That is the reason Play has it.
The same reason mongo use it - it is a good idea to store data in the same format as user query it and save it. So Why mongo use BSON but JSON ? Well, BSON is the same as JSON but have additional properties on every value - data length and data type. The reason of this - when you are looking a lot of data (like db query do) you need to read all the object in JSON to get to another one. We can skip reading in the case if we will know the length of the data.
So You just do not need any BSON readers in JS (it could be somewhere but rarely used) because BSON is format for inside DB usage.
you can read this article for more inforamtion
I am trying to learning HTML5's IndexedDB with mozilla' tutorial Using Indexed DB.
I understand that IndexedDB is object store implementation. But all the examples I tried, they are storing simple objects with key:value pairs. But how would I save a nested or hierarchical objects? For example parent object and have a list of child objects. What is the best way to deal with complex object structures into Indexed DB?
I know the OOPS representation or XML representation of parent-child objects.
How would I achieve it in IndexedDB? Any tutorial source will be very helpful.
they are only storing key:value pairs. But how would I save a nested object?
What is nested object? You can store any object that can represent by JSON (or more correctly serializable by structured cloning algorithm). Is that nested object? You can convert any OOPS into JSON and get it back through its construction. For XML, just store serialized string format.
If you refer relationship, it is different question. I have write a bit about IndexedDB relationship. Modeling a relaionship in IndexedDB is not a problem. In fact, it support very well.
I'm sitting on a CSV import into a database trying to think of ways to add more data without having to change the API (add new fields).
Since working with JSON quite a bit on the client, I'm thinking of storing data into MYSQL as JSON string. So if I have a field
image_filenames
Where I'm currently storing data like this:
img123.jpg
WOuld it make sense to store multiple images in a JSON array like so:
{"img_base":"img123.jpg", "img_alt_1":"img123-1.jpg", "img_alt_2":"img123-2" }
I can deserialize server side, so it woudn't be much of a problem to grab the image I need from the JSON array, while it does not bloat up the API.
Question:
I can't find anything at all on importing CSV with JSON strings. So, what's good and bad in doing so? Are there security concerns (SQL-injections)?
Thanks!
Transferred from comments to here:
If you have a data model scheme that changes or is inconsistent, then the relational database storage isn't the best choice. Sure, you can serialize it and store as binary string, but why? IMO, and I'm not a fan of NoSQLs, but MongoDB looks like something you might make use of. Its document scheme is JSON-based, it'd be familiar to you if you work with JSON-based code on a daily basis. I'd use that to store the data rather than relational db.
Non-relational ones do less work, so they work faster in some scenarios. They also don't have a scheme, so there's no alter table statement as such, therefore you can add "columns" as much as you like. If you don't have relations and need something to store data in JSON format, but that it can be searchable - MongoDB would be great.