_ids of NSManagedObjectObjects

17 views
Skip to first unread message

Florion COIFFÉ

unread,
Jun 1, 2015, 11:39:25 AM6/1/15
to mobile-c...@googlegroups.com
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 :)

Jens Alfke

unread,
Jun 1, 2015, 12:06:09 PM6/1/15
to mobile-c...@googlegroups.com
On Jun 1, 2015, at 7:55 AM, Florion COIFFÉ <cflo...@gmail.com> wrote:

1. since we don't have any control over it, is it truly unique in any situation ? 

The class documentation says "An NSManagedObjectID object is a compact, universal identifier for a managed object. This forms the basis for uniquing in the Core Data Framework.” To me that says it’s a UUID, so yes it’s unique.

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 believe 128 bits of randomness is considered enough for uniqueness, and you can represent that in ~24 ASCII characters using base64 encoding. So 59 bytes seems kind of long.

I don’t know if Core Data can use other sources of object IDs besides NSManagedObjectID, though. Pasin might know.

—Jens

Pasin Suriyentrakorn

unread,
Jun 1, 2015, 7:27:01 PM6/1/15
to mobile-c...@googlegroups.com
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, 


* 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É <cflo...@gmail.com> wrote:

--
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 mobile-couchba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/7d1305a5-d487-4c6b-a9d5-609ca0970479%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Florion COIFFÉ

unread,
Jun 2, 2015, 6:41:57 AM6/2/15
to mobile-c...@googlegroups.com
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, 


* 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
Reply all
Reply to author
Forward
0 new messages