Any takers? I'm going forward with it but I've still got the question of how to best handle CBL attachments.
Perhaps storing each attachment as a separate CKRecord would be ideal. If an attachment is added, updated, or deleted, I could just add, update, or delete the associated CKAsset object and have it removed from the CloudKit servers. However, I'm pretty sure that CBL uniques the attachment .blob files. That is, if multiple CBLDocuments have the same file attached, there's only one instance of that attachment .blob file stored in the CBL database. Is that a correct assumption? That's a very efficient way of storing the attachments. I would like to mimic that on CloudKit if I can to reduce storage consumption, but I also need to manage deleting them in CloudKit only when they're purged locally. If multiple CKRecords referenced the same CKAsset via a CKReference that could get tricky to keep the server in sync with the local. How does Sync Gateway handle that? Remember, CloudKit doesn't have any back-end smarts that I could write code to manage this issue. It all has to be done from the client side. Thanks, Brendan On Saturday, August 27, 2016 at 7:02:54 PM UTC-6, Brendan Duddridge wrote: > > Hi, > > I'd really like to add CloudKit syncing to my app and I was wondering what > the best approach would be for integrating it with CouchbaseLite (iOS). > > In a previous post I suggested generating files that contain all the > changes and then processing them on each device, keeping track of the last > file that was synced. > > But now I'm thinking a better solution would be to use CloudKit and store > CBLDocument properties into CKRecord objects. > > What I'm wondering is what would be the best approach for this? > > Should I simply store a one-to-one mapping of CBLDocument objects > (representing the most current revision) to CKRecord objects? > > What if a CBLDocument is updated or deleted? > > Instead of storing CBLDocument objects into CKRecord objects, should I > store CBLRevisions into CKRecords basically keeping a running log of all > the changes over time? > > If a CBLDocument is updated or deleted locally, maybe I should just > replace the associated CKRecord in CloudKit with the updated most recent > local revision? > > What about document attachments? > > There's the CKAsset class for that, but I'm wondering if maybe it's best > to have a separate CKRecord for each attachment and relate that to the main > CKRecord that represents the CBLDocument? Then if an attachment is updated, > I just just find the corresponding CKRecord and update its attachment. > > Processing the changes from CloudKit would just be a matter of converting > each CKRecord into a CBLDocument and calling > putExistingRevisionWithProperties > on it. > > I know these are a lot of unanswered questions. I'm just trying to find > out what the best way to support CloudKit would be. > > Official support for this from Couchbase would be an amazing addition for > all iOS and Mac CBL developers. > > If anyone wants to collaborate with me further on this that would be > amazing. Multiple minds working on the problem would be much better than > just me alone. > > Thanks, > > Brendan > -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/1d1812e0-9bef-4347-ae19-2348c375bedd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
