Make it possible to overwrite client id prefix; also enables catching duplicate ids & cids

[doublerebel]

Currently, uid can never detect id or cid collisions because it has no idea of the prefix set for cid.

I believe because uid is only called in one place, the prefix should be set at uid. Then uid can be overridden to provide a custom prefix and also to detect collisions. Therefore it will be a truly "unique id".

I discovered this problem when extending the model to use local storage.

For example:

Using Spine.Model.Local
say Local has ids c-1
fetch() then will end up assigning cid c-0 to item with id c-1

Then in create...

...create new id, will have cid c-1, which is then set as id...

@id          = @cid unless @id

...and then overwrites the old record...

@constructor.records[@id]   = record
@constructor.crecords[@cid] = record

...this is further finalized when saving.

[doublerebel]

After this patch is applied, catching duplicates is as easy as this commit:
doublerebel@759ef73

[maccman]

Sorry, I'm still struggling to understand the issue. Can you provide a simple test case demonstrating it?

[maccman]

Does my latest push fix this?

[maccman]

@doublerebel ping

[doublerebel]

Yes, commit e06166 to detect duplicates does solve the duplicate id issue. For reference, I've uploaded the test case. The meat of it is here:
https://github.com/doublerebel/spinebugexample/blob/master/app/index.coffee

The example is running with Spine 1.0.7 from npm at http://lager.doublerebel.com:9001/
The same example with Spine from Github master is running at http://lager.doublerebel.com:9002/

As can be seen in either example, uid is called at least twice for every create -- possibly more in the latest version as uid is now recursive. The patch in pull req 319 will prevent the extra calls.

[doublerebel]

Separately, I had moved 'c-' into the uid fn for the case when a custom clientside id scheme is required. Having 'c-' in the constructor is difficult to overwrite. If it is instead hardcoded in find or uid then those methods can be easily be extended and overwritten.

[aeischeid]

think some of what you were going for in this was handled by #451