I want to serialize all of the data in my realtime document to a string with which I can later initialize a new realtime document. I want to do this so my users can make copies of their drive files, save different versions, etc, and I can re-initialize the relevant realtime documents from the string.
I see I can call document.getModel().getRoot().toString() to get a string representation of the root CollaborativeMap, but I don't see any easy way to load that string back IN to a CollaborativeMap. Also, the string returned is not JSON, so I can't easily use JSON.parse to turn it back into a normal JS object and iterate from there.
I can make this work by hand. Is there any easy automated way?
You can do that on the service side using the realtime.get() and update() methods:
https://developers.google.com/drive/v2/reference/realtime
Related
In my mobile app I have an object implementing PropertyBusinessObject which contains numerous other objects also implementing this interface. This object structure is populated by JSON data I am getting back from my server. When I try to write this object to Storage with writeObject() I get the above error. The stacktrace shows it originating in the com.codename1.io.Util.writeObject() method where it is writing UTF-8 (limited to 64k). The developer guide does not reference any potential issues with Storage and recommends it over FileSystemStorage. My question is, is there a workaround/update for this? Would I have to revert to writing out the object structure to the filesystem? Thanks.
If you have a ridiculously long string e.g. to represent the contents of the file I would suggest rethinking that. Strings are inefficient in Codename One since we need to copy their representation into the iOS native layer. Also writing them to UTF is very wasteful if what you need is a binary representation. I suggest using a byte array.
Serializing to storage is a simple approach. It works great for small objects. If you have larger objects you might want to store them individually. You can also serialize to/from JSON so your storage data is readable.
The documents in my apps collection each contain a subcollection of users. Now I need to update a single user per app given a set of _ids for the apps collection using javascript. I cannot use a regular call to update() for this, as the data inserted will be encrypted using a public key stored within the app document. Therefore the data written into the user-subdocument is dependant on the app-document it is contained in. Pseudo-code of what I need to do:
foreach app in apps:
app.users.$.encryptedData = encrypt(data, app.publicKey)
One way to do it would be to find all the apps and then use forEach() to update every single app. However, this seems to be quite inefficient to me, as all the app-documents would have to be found twice in the database, one time to gather all of them and then another time to update every single document. There has to be a more efficient way.
The short answer is that no, you can not update a document in mongoDB with a value from that document.
Have a look at
https://stackoverflow.com/a/37280419/5293110
for ideas other that doing the iteration yourself.
New to backbone/marionette, but I believe that I understand how to use backbone when dealing with CRUD/REST; however, consider something like results from a search query. How should one model this? Of course the results likely relate to some model(s), but they are not meant to be tied to said model(s).
Part of me thinks that I should use a collection using a model that doesn't actually sync with a data store through the server, but instead just exists as a means of a modeling a search result object.
Another solution could be to have a collection with no models and just override parse.
I assume that the former is preferred, but again I have no experience with the framework. If there's an alternative/better solution than those listed above, please advise.
I prefer having one object which is responsible for both request and response parsing. It can parse the response to appropriate models and nothing more. I mean - if some of those parsed models are required somewhere in your page, there is something that keeps reference to this wrapper object and takes models from response it requires via wrapper methods.
Another option is to have Radio (https://github.com/marionettejs/backbone.radio) in this wrapper - you will not have to keep wrapper object in different places but call for data via Radio.
What method do I have to override so as to extend Ext.data.reader.Json (for a TreeStore)?
My new Reader must just take json object already parsed by base Reader class and rearrange several items in it. I just need to understand which Reader method is invoked by Proxy when Proxy wants to get parsed data.
getResponseData is where it gets the data from the response and puts it into an appropriate format for the reader. Here you could make transformations to the JSON and then just let the reader do it's thing.
readRecords is where it turns the JSON into models, so you could also modify that.
The absolute latest is in onProxyLoad in Ext.data.Store, where it gets the returned records from the response & calls the loadRecords method to populate the store.
If it were me I would make an effort to do the first method, since it's the easiest thing to override.
Hi I am using an NSTreeController to control an NSOutlineView. This application loads bookmarks from file to application. As in the SourceView example in ADC:
http://developer.apple.com/mac/library/samplecode/SourceView/index.html
My questions is how do I save the bookmark to file once user makes the changes. Should I maintain the array/tree internally in my application and save before quitting or is there any easier methods?
You want to reverse the action taking place in the populateOutline method of MyWindowController.m. This method is reading the plist into one dictionary, reading a value from that dictionary, and using it to build the tree. Start with that method and follow the code to see how it is building the tree. It's using the BaseNode and ChildNode classes to build up the data model as a tree (I'm not sure why they didn't just use NSTreeNode). You want to reverse that procedure, ending up with an NSDictionary. You can then use writeToFile:atomically: to save the dictionary back to disk.
This can get as complex as you'd like to make it. For instance, the current code loads the dictionary file in a separate thread, so you could save in a separate thread, too. Or, you might want to save after every edit, again in a separate thread.