I’m in the process of migrating an existing solution into Couchbase. In the solution I have some “Photo” entities with scaled down photos (approx. 50-200KB) and I want to sync them to the mobile devices. To ensure transparency and avoid some issues people have been writing about (though these may be old/solved) I decided to Base64 encode the images and just save them as text. Actually, I did a similar thing for Dates (ie. ISO format as text).
However, as I’m now working on the mobile side I have become uncertain whether this is really needed. I have seen in several places that there are special handling for exactly blobs/attachments and Dates.
So I have been trying to find examples of how to simply save a binary file on my JsonDocument in Java on the server side - and haven’t really been able to - apart from a 2 year old example of how to split attachments into several documents. But I really just want to add two (the photo and a thumbnail) to my JsonDocument. Can I do that? And should I prefer that to Base64 encoding it? And if so, how can I do it?
I cannot find a method to save an attachment nor a date… I can only do a
JsonDocument doc = JsonDocument.create("id1" JsonObject.empty());
but then how do I read these again? There seem to be no methods to read a Date object nor a binary image object?
I seem to be able to read a Date and Blob object directly from a record in my ResultSet from a query:
I have not yet looked into saving the same type of information from the mobile side - but finding these methods in C# made me consider if I was doing this incorrectly. There really is no reason to convert back and forth manually if it is not needed
I’m using Java SDK 2.7.1 on my server (and C# SDK 2.1.2 on the mobile side). The server is Community Edition 6.0 and Sync Gateway 2.1.1
Server itself doesn’t support attachments. Sync Gateway adds APIs for these, for compatibility with mobile. So to create a doc with attachments you’ll need to use the Sync Gateway REST API.
Both mobile and the server SDKs have some convenience functions for dates, but be aware that they are stored simply as strings formatted according to ISO8601. (JSON has no ‘date’ type.)
The server does support storing binaries in items directly though, which SyncGateway does not directly support other than through the attachment API.
This is one of those areas where there is a difference between the two approaches that needs resolution in the future.
Agreed, but a document consisting of raw binary data isn’t the same as an attachment, which is binary data associated with a JSON document, and with optional metadata. That’s why I said server doesn’t natively support attachments.
In terms of getting to a solution, I think what you’re suggesting here is the best solution across mobile and web at the moment. Store the content encoded in the JSON document body. At the app level, you can add any metadata/permissions.
If you need any help with a sample, we can probably get something together.
Thanks @jens and @ingenthr for sharing your thoughts.
It sounds as if this is an area that still needs a little development
But if I understand you correctly then my current implementation is the way to go:
- When saving the attachment I Base64 encode it and store the “string” as an attribute in the document
- When I need to show it I Base 64 decode it back to an image (bytes/stream whatever is needed)
Both of the above are the way to go whether that being in the web app on the server or in the mobile app.
Then synchronisation of the data through Sync Gateway works straight out of the box.
I was just curious after having seen the methods in the C# API - I really don’t want to “over-engineer” this
It’s not preferred (it increases document size), but it’s a workaround for when it’s not feasible to use the SG REST API to create those documents.
Ok, then I misunderstood your (comment by @ingenthr) recommendation
So, I need to save the images both on the server side (through the Java SDK) and in the mobile app (C# SDK and CB Lite - also offline).
If you have some examples of how I should do that the “preferred” way (from both sides) then I would really appreciate that. I’m in the process of building this so I can change it at the moment.
I guess it depends on what you mean by “preferred”. The optimal solution for large blobs is to use attachments. The optimal solution for ease of use on both mobile, server and web is to base64-embed the blob in a JSON document. Someday we’ll have something optimal for both, but not today.
Well, I was only using “preferred” after your comment about it not being the preferred solution.
But I guess from what you say that for now the right solution is to use the base64 encoding/decoding model for this project.