Currently we are extracting the UUID path (last section after letter p) of the Core Data ObjectID referenced to an NSManagedObject object to use for the corresponding CBL Document.
For example, * CoreData Object ID: x-coredata://1FE9AE14-C6A6-4DE9-9AF2-9EBDB203D507-71166-0001E4B7754C8989/Entry/pCBLAA3DC50B-3869-4359-9FF9-8BEC6F3E1D6F-71166-0001E4B7756E69AE<x-coredata://1FE9AE14-C6A6-4DE9-9AF2-9EBDB203D507-71166-0001E4B7754C8989/Entry/pCBLAA3DC50B-3869-4359-9FF9-8BEC6F3E1D6F-71166-0001E4B7756E69AE> * CBL Document ID: CBLAA3DC50B-3869-4359-9FF9-8BEC6F3E1D6F-71166-0001E4B7756E69AE The ID seems to be long, but it’s a simple solution without any algorithm on top to convert a Core Data Object ID to a CBL Document ID anytime. 2. the generated string's length for the ID is 59. Is too long in terms of memory on the server or not at all ? (I saw the shorter the better in terms of memory footprint) I think it would have impact memory usage on the server side (e.g. sync gateway’s channel cache) but more likely the impact would be linear. Are you currently seeing any memory issues regarding the long length of the document ids? 3. Would prefixing it with the type of the object be a good practice or not ? (ex: person_17162-1817DHDHD-XXXX...) Is is doable ? Could you explain more about your use cases of prefixing the type to the ID? Currently we are adding entity name to the type property of the document. 4. The Category is on NSManagedObjectID, wouldn't it be more flexible if it was on NSManagedObject ? (in order to generate our own uniqueIDs) I don’t really know if that is going to cause any issues on the Core Data side or not. — Pasin On Jun 1, 2015, at 7:55 AM, Florion COIFFÉ <[email protected]<mailto:[email protected]>> wrote: CBLIncrementalStore is amazing. But there is something I see as a limitation. To generate unique IDs I noticed that you use [NSManagedObjectID URIRepresentation]. I'm just wondering: 1. since we don't have any control over it, is it truly unique in any situation ? 2. the generated string's length for the ID is 59. Is too long in terms of memory on the server or not at all ? (I saw the shorter the better in terms of memory footprint) 3. Would prefixing it with the type of the object be a good practice or not ? (ex: person_17162-1817DHDHD-XXXX...) Is is doable ? 4. The Category is on NSManagedObjectID, wouldn't it be more flexible if it was on NSManagedObject ? (in order to generate our own uniqueIDs) Thanks :) -- 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]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/7d1305a5-d487-4c6b-a9d5-609ca0970479%40googlegroups.com<https://groups.google.com/d/msgid/mobile-couchbase/7d1305a5-d487-4c6b-a9d5-609ca0970479%40googlegroups.com?utm_medium=email&utm_source=footer>. For more options, visit https://groups.google.com/d/optout. -- 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/D164828F-B5E7-4D43-8A52-5D96BB95C17D%40couchbase.com. For more options, visit https://groups.google.com/d/optout.
