Thanks a lot for your answers! 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/p > CBLAA3DC50B-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? >
Yes I mean on the server side. I am not seing memory issues since I'm in the process of setup everything. But you're right, this would be linear, it will just need more memory :) You're right this is not a real problem. Thx! > > 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. > I actually read that somewhere in couchbase documentation. But besides readability, I don't really see the need to do it. The type property is clean and perfect, thanks. > > 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. > I actually have a use case for this, which causes a problem. Here's an example with a ToDo app: Let's imagine in our datamodel we have 2 types of objects: Task (fields: creationDate, name) and Tag (fields: creationDate, name). A Task is the actual todo and a Priority (ex name: urgent, normal, idle) is associated to a Task. In our use case, a Task always has a default Priority with name "urgent". Priority objects are not created in advance (lazy created). The unicity of an object is defined by NSManagedObjectID which is a randomly generated value. *First example that works:* - On DeviceA, I tap on the "Create a task" button. - Task1 is created, since Priority with name "urgent" doesn't exist, it is created (Priority1) and associated to the newly created task object. - A few seconds later I look at DeviceB, I see the task I created on DeviceB - I tap on the "Create a task" button. - Task2 is created, since Priority with name "urgent" exists (Priority1), I just associate it to the Task2 object --> I have 3 objects: *Task1, Task2, Priority1* *Second example that doesn't work:* - On DeviceA and DeviceB, I tap on the "Create a task" button *at the same time*. - On DeviceA: Task1 is created, since Priority with name "urgent" doesn't exist, it is created (Priority1) and associated to the newly created task object. - On DeviceB: Task1 is created, since Priority with name "urgent" doesn't exist, it is created (Priority2) and associated to the newly created task object. ---> I have 4 objects: *Task1, Task2**, Priority1**, Priority2* ---> Since, before they have time to sync, Devices don't know that another device maybe be creating a Priority object, they all create one. And Since NSManagedObjectID i randomly generated, so not deterministic, they functionally are the same object, but they're not technically. In a previous project, what I did with Ensembles ( https://github.com/drewmccormack/ensembles): - for unicity of object, Ensembles lets you control what unique ID to give to an object. More precisely, when an object is created, a delegate is called and ask you "give me a unique ID for this object". And here you have the choice to return NSManagedObjectID, or the name property of the object. Me, I added a clientID property to all objects (which was set in awakeFromInsert method with a UDID I generate), so I returned the clientID to Ensembles for each object. - the client ID was: "typeOfTheObject_theUDID" (ex: "task_1717177171-19191919191-11818JDJDJDJ-DJDJDJ"). - So, for such a case I would do this hack: the clientID of Priority would be the UDID of the task creating it but replacing "task_" by "_priority_" (ex: priority_1717177171-19191919191-11818JDJDJDJ-DJDJDJ) ---> this make it deterministic and when DeviceB receives a Priority object with the same clientID as the one it has, it knows it's the same object I'm sorry for this long message, it's hard for me to explain this simply :( Thank you :) Florion > > — Pasin > > On Jun 1, 2015, at 7:55 AM, Florion COIFFÉ <[email protected] > <javascript:>> 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] <javascript:>. > 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/baa09e90-442a-4ad4-9013-af7e32f9cd54%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
