search

jakartaee / persistence

https://jakartaee.github.io/persistence/
Other
191 stars 55 forks source link

GenerationType and identifier type #407

Closed gavinking closed 12 months ago

gavinking commented 1 year ago

I might be missing something, but the spec appears to be silent on the issue of which id types correpond to which GenerationTypes. I think it should explicitly specify something like this:

Thoughts?

beikov commented 1 year ago

String for AUTO? I don't know if that's a good idea. Other than that, looks reasonable.

sebersole commented 1 year ago

I think the idea is UUID-as-String. It's AUTO, so "the persistence provider should pick an appropriate strategy"

dmatej commented 1 year ago

I expect that on the right side are java types. So ie. for current Postgres it is UUID:UUID, but for some older database it can be VARCHAR:UUID. EDIT: Mea culpa, I should read slowly.

gavinking commented 1 year ago

String for AUTO? I don't know if that's a good idea. Other than that, looks reasonable.

Ah, right, I thought we already said that, but actually we don't. So I would change:

In the case of a field or property of type java.util.UUID, the AUTO strategy is equivalent to UUID.

To:

In the case of a field or property of type java.util.UUID or java.lang.String, the AUTO strategy is equivalent to UUID.

trajano commented 12 months ago

Can UUID be applied to byte[] so long as it is 16-bytes. For byte[] and AUTO same semantics but can be arbitrary sized array

For completeness: For byte[] and IDENTITY same semantics but can be arbitrary sized array but it is a binary sequence of Little-Endian (or Big-Endian, whichever you guys think is appropriate)

gavinking commented 12 months ago

Section 2.4 does not list byte[] as a valid primary key type.

So that would be an orthogonal change.

trajano commented 12 months ago

Section 2.4 does not list byte[] as a valid primary key type.

Actually thinking about it, it would be insane for anyone normal to work on the UUID or AUTO as byte[]. I don't think it's worth it.

For one if this was done, the vendor needs to convert byte[] to a ByteBuffer so comparisons can be made. In addition, it would need ByteBuffer as another option.

But as I stated, no sane architecture I think would use this. Short of those that need that extra bit of performance and space savings since ByteBuffer or byte[] as I noted earlier do not need to be 16-bytes and can be say 2-bytes for a 64k record max reference table lookup.