ForumsDevelopersBest Practice for New Item Ids
Best Practice for New Item Ids
Author | Message |
---|---|
mike |
Ah, the dreaded integer unique id. There's never a good solution. What is the best practice recommended for creating an ID value for new objects (task, notebook, folder, context, location, etc.). The documentation doesn't really address what happens here. Do we make up a number and when added a new Id is assigned and returned? How can we ensure that there was no item added on the server side that has the same id as the made up id? Must we pass a negative number or a 0? Please advise.
|
Jake Toodledo Founder |
Toodledo will create unique IDs for you when you add an object. You do not need to create your own ID numbers. If your software needs to have an ID for an object even before it has had a chance to sync, then I suggest that you keep both a local id number and a Toodledo id number. The local id will be assigned however you want and the Toodledo id will be assigned by us.
|
mike |
The big issue is correlation of new items. I think I can use meta for tasks, but not notebooks, so suppose I have two new notebooks. I give them local ids of -1, -2. they are titled "test1" and "test2". when i sync, i get back an array of notebooks. "test1" with an id of 12345 and "test2" with an id of 12346. now to update my local database, i have to "find" each of these, and merge/remove/replace. to find, i look up by id. the id has changed, so i can't find it. since there is no metadata i can attach, there is no point of correlation, except for the title. the title is not unique, so there may be an existing item called "test1" in the database. which one to update? additionally, i could have had both new notebooks called "test", in which case i can't even use the logic of updating the newly added one, because they would both match that criteria as well.
with no correlation data that can round trip (i.e. client generated id or at least uniquely identifying metadata), i don't see how you can safely make this sync. single-item adds would prevent this problem, but that's an expensive trade off. as far as tasks go, i guess i can use "meta" fields, although i would not want the meta to persist once i round-tripped a sync. |
Jake Toodledo Founder |
I see your point. You should know that the array of notebooks returned from the "add notebook" API is in the same order as the JSON object that you submitted. You can use that order to correlate. In other words, if you add {"NotebookA", "NotebookB"} we will return {"NotebookA ID=123", "NotebookB ID=135"}
I suppose a nicer way to handle this would be for us to support a pass-through reference number, so you could pass an internal ID with each add, and it would echo that back when on success/error. I'll put this on our to-do list. |
Jake Toodledo Founder |
Ok, that was easy. We just added a passthrough reference number. It is undocumented at the moment, so if you want to use it, set the "ref" variable when adding a task/notebook and it will be echoed back to you.
/2/tasks/add.php?tasks=[{"title":"Task","ref":"1"}] This message was edited Dec 21, 2010. |
mike |
Wow, quick and awesome. Thanks for the help.
|
mike |
Is that for notebooks, goals, locations, etc. as well?
|
Jake Toodledo Founder |
Tasks and notebooks only, since they are the only ones that allow bulk adding at the moment, and so they are the only ones that need it.
|
andrew |
Hi,
I have been relying on the fact that the new id's come back in the same order as the new tasks were uploaded. Is that a safe assumption? Thanks, Andrew |
Jake Toodledo Founder |
Yes, this is a safe assumption. You can also use the ref passthrough if you want to be extra safe.
|
andrew |
Great, thanks!
|
You cannot reply yet
U Back to topic home
R Post a reply
To participate in these forums, you must be signed in.