For the application it's a String. JPA doesn't need to know whether this String
represents a uuid or a random number you did yourself. It just needs to be
unique!
LieGrue,
strub
> On Tuesday, 12 April 2016, 17:08, Francesco Chicchiriccò
> <ilgro...@apache.org> wrote:
> > On 12/04/2016 16:11, Mark Struberg wrote:
>>> you are not interested in making the approach below more general -
>> 'not interested' is not the right word. Not on my personal list of
> important things for me personal - but happy to get patches!
>
> Sure :-)
> But then I need some hint in finding how to recognize when the mapped
> field is java.util.UUID (rather than String).
>
>>> 4. I have opened OPENJPA2640 and provided a patch
>> Thanks a lot, trying to get around it the next days. Feel free to poke me
> for it ;)
>
> Perfect, thanks.
> Regards.
>
>
>>> On Tuesday, 12 April 2016, 15:51, Francesco Chicchiriccò
> <ilgro...@apache.org> wrote:
>>>> Hi Mark,
>>> with reference to my 4 questions below:
>>>
>>> 1. I have experimented that, even though UUIDType4HexSeq provides a
>>> static getInstance() method, it is not called with my use case, so I am
>>> fine with my UUIDGenerator's constructor being invoked twice (e.g.
> one
>>> time for each entity)
>>>
>>> 2. I have been able to translate the sequence generator definition to
>>> orm.xml
>>>
>>> 3. I understand that since "some DBs are not really working with
> it",
>>> you are not interested in making the approach below more general -
>>> that's fine, we are going to use it anyway, for the DBs we support
>>>
>>> 4. I have opened OPENJPA2640 and provided a patch, please take a look -
>>> incidentally, I have noticed that 2.4.1 appears as unreleased in JIRA
>>>
>>> Regards.
>>>
>>>
>>> On 12/04/2016 09:22, Mark Struberg wrote:
>>>> Hi Francesco!
>>>>
>>>> I usually let the PK be a String and create the UUID myself in
> Java.
>>>>
>>>> The 'uuid' generator is a nice feature but it's not
> portable.
>>>>
>>>> And that might be the reason why some DBs are not really working
> with it -
>>> it's simply not that frequently used.
>>>>
>>>> There are 3 ways to create the UUID.
>>>>
>>>> a.) In the default ct. That might trigger a tad too often and
> might slow
>>> down selects, etc.
>>>> b.) Lazily in getId(). If null -> create a new UUID
>>>> c.) Via an own ct which takes the UUID pk. You basically create
> the ID in
>>> your business layer.
>>>> I mostly use c) if I need a UUID pk.
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>
>>>>
>>>>> On Monday, 11 April 2016, 9:02, Francesco Chicchiriccò
>>> <ilgro...@apache.org> wrote:
>>>>>> Hi all,
>>>>> I went further and built a sample POC [10] which mimics the
> essentials
>>>>> from Syncope.
>>>>>
>>>>> I have defined an UUIDGenerator implementing Seq (and relying
> on [3]
>>> for
>>>>> UUID generation), and declared it via
>>>>>
>>>>> @SequenceGenerator(name = "uuid", sequenceName =
>>>>>
> "net.tirasa.ilgrosso.uuidpoc.openjpa.UUIDGenerator()")
>>>>>
>>>>> in the @MappedSuperclass of both JPA entities available, plus
> defined
>>>>>
>>>>> @Id
>>>>> @GeneratedValue(strategy = GenerationType.SEQUENCE,
> generator =
>>>>> "uuid")
>>>>> private UUID id;
>>>>>
>>>>> in both entities.
>>>>>
>>>>> I have also extended the H2Dictionary to support the native
> UUID type
>>>>> (without such extension, the id column would have had type
> BLOB).
>>>>>
>>>>> All this above seems to work - at least for the simple JUnit
> test case
>>>>> provided; I have some questions, though:
>>>>>
>>>>> 1. I have experimented that UUIDGenerator is instantiated
> twice: would
>>>>> it be possible to defined it as singleton - as it happens for
>>> OpenJPA's
>>>>> UUIDType4HexSeq?
>>>>>
>>>>> 2. How would the @SequenceGenerator annotation translates to
> orm.xml?
>>>>> I've attempted the bare translation but it did not work.
>>>>>
>>>>> 3. The extended logic I have put in my H2Dictionary looks
> quite poor
>>> for
>>>>> the general case - even though good enough for my specific
> use case:
>>>>>
>>>>> @Override
>>>>> public String getTypeName(final Column col) {
>>>>> return col.getType() == Types.BLOB &&
>>> (col.isPrimaryKey() ||
>>>>> col.isForeignKey())
>>>>> ? "UUID"
>>>>> : super.getTypeName(col);
>>>>> }
>>>>>
>>>>> How much difficult would be to make it proper, e.g. recognize
> when the
>>>>> class field is java.util.UUID? I'll need such extension
> for MySQL,
>>>>> MariaDB, PostgreSQL, MS SQL Server and Oracle dictionaries.
>>>>>
>>>>> 4. I am used to rely on openjpa-maven-plugin to generate the
>>>>> database.sql file; how can I configure it to use my
> H2Dictionary, and
>>>>> not the default?
>>>>>
>>>>> Thanks for your support.
>>>>> Regards.
>>>>>
>>>>> On 04/04/2016 10:49, Francesco Chicchiriccò wrote:
>>>>>> Hi all,
>>>>>> in Syncope we are currently discussing [1] the option
> to replace
>>> our
>>>>>> table generators-based id strategy to something else,
> based on
>>> UUID,
>>>>>> which seem to offer several advantages.
>>>>>>
>>>>>> I have found [2], but I would rather prefer to
> generated UUID
>>> values
>>>>>> manually (via [3] which seems to offer better
> performance and
>>> more
>>>>>> features than the standard JDK's).
>>>>>>
>>>>>> In order to do so, I would replace the current
>>>>>>
>>>>>> @Id
>>>>>> private Long id;
>>>>>>
>>>>>> public Long getKey() {
>>>>>> return id;
>>>>>> }
>>>>>>
>>>>>> in [4], backed by [5], with something like as
>>>>>>
>>>>>> @Id
>>>>>> private UUID id;
>>>>>>
>>>>>> public UUID getKey() {
>>>>>> synchronized(this) {
>>>>>> if (key == null) {
>>>>>> key = ... // generate via JUG [3]
>>>>>> }
>>>>>> }
>>>>>> return key;
>>>>>> }
>>>>>>
>>>>>> As Syncope supports several DBMSes, I would also like
> to empower
>>> the
>>>>>> underlying capabilities for storing such values:
>>>>>>
>>>>>> * UUID Type for PostgreSQL [6]
>>>>>> * UNIQUEIDENTIFIER for SQL Server [7]
>>>>>> * RAW(16) for Oracle [8]
>>>>>> * BINARY(16) with some optimizations for MySQL /
> MariaDB [9] or
>>>>>> vanilla with H2
>>>>>>
>>>>>> Do you have any suggestion about:
>>>>>>
>>>>>> (a) the way how I am planning to support UUID
> generation
>>>>>> (b) the cleanest way to support DBMS differences
> (extending the
>>>>>> respective DB dictionaries?)
>>>>>>
>>>>>> TIA
>>>>>> Regards.
>>>>>>
>>>>>> [1] http://markmail.org/message/fhdrwerdwdm3opdx
>>>>>> [2]
>>>>>>
>>>
> http://openjpa.apache.org/builds/2.4.1/apache-openjpa/docs/jpa_overview_meta_field.html#jpa_overview_meta_gen
>>>>>> [3] https://github.com/cowtowncoder/java-uuid-generator
>>>>>> [4]
>>>>>>
>>>
> https://github.com/apache/syncope/blob/master/core/persistence-jpa/src/main/java/org/apache/syncope/core/persistence/jpa/entity/user/JPAUser.java
>>>>>> [5]
>>>>>>
>>>
> https://github.com/apache/syncope/blob/master/core/persistence-jpa/src/main/resources/META-INF/spring-orm.xml#L87-L94
>>>>>> [6]
> http://www.postgresql.org/docs/9.3/static/datatype-uuid.html
>>>>>> [7]
>>>>>>
>>> http://wiki.ispirer.com/sqlways/sql-server/data-types/uniqueidentifier
>>>>>> [8]
>>>>>>
>>>
> http://docs.oracle.com/cd/B28359_01/server.111/b28286/functions175.htm#SQLRF51816
>>>>>> [9]
>>> https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/
>>>>> [10] https://github.com/ilgrosso/OpenJPAUUIDPOC
>
> --
> Francesco Chicchiriccò
>
> Tirasa - Open Source Excellence
> http://www.tirasa.net/
>
> Involved at The Apache Software Foundation:
> member, Syncope PMC chair, Cocoon PMC, Olingo PMC, CXF committer
> http://home.apache.org/~ilgrosso/
>
