re-use of creation id across types

[Ricardo Signes]

A while ago we discussed how backrefs behave in the face of duplicate creation ids. The spec was amended to cover this in 72f845e5.

> Creation ids sent by the client SHOULD be unique within the single API request for a particular data type.

The "for a particular data type" indicates to me that a given creation id can be used multiple times, so that you can setFoos create "xyz" and setBars create "xyz" and then "#xyz" is unambiguous because its placement tells us the type of object we're referencing (unless we introduce polymorphic backrefs!).

I want to be sure that we agree on this. Today I was looking at a JMAP implementation and saw an undivided backref namespace, which would break the above guarantee.

Thanks!

--
rjbs

[Neil Jenkins]

On Fri, 3 Feb 2017, at 06:11 AM, Ricardo Signes wrote:

The "for a particular data type" indicates to me that a given creation id

can be used multiple times, so that you can setFoos create "xyz" and

setBars create "xyz" and then "#xyz" is unambiguous because its placement

tells us the type of object we're referencing (unless we introduce

polymorphic backrefs!).

Yes, there are no polymorphic foreign references, so the creation id should be scoped to the particular type, and thus unambiguous in that example. I'll expand this portion of the spec; how about:

Creation ids are scoped by type; a separate `creation id -> id` map MUST be kept for each type. Foreign key references are always for a particular record type, so use of the same creation key in two different types cannot cause any ambiguity. Creation ids sent by the client SHOULD be unique within the single API request for a particular data type. If a creation id is reused for the same type, the server MUST map the creation id to the most recently created item with that id.

Neil.

[Ricardo Signes]

* Neil Jenkins <ne...@fastmail.com> [2017-02-02T22:20:50]
> *Creation ids are scoped by type; a separate `creation id -> id` map

> MUST be kept for each type. Foreign key references are always for a
> particular record type, so use of the same creation key in two different
> types cannot cause any ambiguity. Creation ids sent by the client SHOULD
> be unique within the single API request for a particular data type. If a
> creation id is reused for the same type, the server MUST map the

> creation id to the most recently created item with that id.*

Looks good to me.

--
Ricardo Signes (rjbs)
Research & Development, IC Group