Hi all,
it seems we are quite on the same page: UUIDs are good for Syncope, for
various reasons; side note: I haven't thought before how this will also
simplify the export / import of configuration as XML, not having to deal
any more with OPENJPA_SEQUENCES...
About the doubts expressed:
* @Massimiliano: I don't believe it would take too much time: my
estimate is for 1~2 weeks at most, once I've understood how to manage
things at OpenJPA level [6]; moreover, I would say that such a step is
for new major releases, so it's something for 2.0 (or 3.0), I would
hardly introduce it in - say - 2.1.
* @Guido: the migration path from 1.2 to 2.0, at least for how it is
being developed [7] is not affected by this change: users (and 1.2
roles, now groups) are meant to be pulled (synced in 1.2 terms) via a
"Syncope" ConnId connector; naturally, if someone uses the Syncope user
id outside of Syncope, this is definitely going to be problematic as you
highlight, even though there are some resolving strategies as replacing
user id with username for external reference, or to map somewhere
externally UUIDs to long.
I have opened SYNCOPE-822 for tracking this.
Regards.
On 04/04/2016 22:22, Guido Wimmel wrote:
I'd also prefer UUIDs over the current primary keys.
However, that would make migrations from 1.2.x to 2.0 even more
difficult than they probably already will be
- especially if someone uses the Syncope user id outside of Syncope.
Cheers,
Guido
Am 04.04.2016 um 15:51 schrieb Colm O hEigeartaigh:
+1 if it is feasible for 2.0.0. Having a unique global Id maps nicely to
the SCIM Id which "MUST be unique across the SCIM service provider's
entire
set of resources.".
Colm.
On Mon, Apr 4, 2016 at 11:11 AM, Massimiliano Perrone
<[email protected]> wrote:
Il 04/04/2016 10:23, Francesco Chicchiriccò ha scritto:
Hi all,
a recent e-mail on user@ [1] (about SCIM) made me reconsider one of
the
choices we've made in Syncope since the beginning, e.g. using table
generators for long primary keys in several entities, and
especially for
users, groups and any objects (and maybe related as attributes,
memberships
and relationships).
It seems that UUID offers several advantages, compared to natural keys
(as "long" we use for the aforementioned entities) [2][3][4].
There is some open source UUID generator around [5], which is
reported to
perform quite better than standard JDK's, and also features time-based
generation, particularly useful in cluster scenarios.
Naturally, all this would mean changing some logic and data
representation, hence a relevant impact on the codebase, but with
considerable improvements in portability and performance.
It is my opinion, after a quick chat with Mark Struberg on
#openjpa, that
this change might worth the effort, and also that we can make it
before
finalizing 2.0.0.
I am going anyway to ask for details on users@openjpa.
WDYT?
It seems to be a good enhancement, my only doubt is only about the
time.
Do you think it's a good idea (I'm supposing that you know how much
time
you need to implement the feature) implementing it before the 2.0.0
release?
Regards,
Massi
[1]
http://syncope-user.1051894.n5.nabble.com/Get-list-of-Users-from-a-Syncope-Group-td5708406.html
[2] http://blog.codinghorror.com/primary-keys-ids-versus-guids/
[3]
http://web.archive.org/web/20150511162734/http://databases.aspfaq.com/database/what-should-i-choose-for-my-primary-key.html
[4]
http://blog.xebia.com/jpa-implementation-patterns-using-uuids-as-primary-keys/
[5] https://github.com/cowtowncoder/java-uuid-generator
[6] http://markmail.org/message/licbo2xitkkh2qhu
[7]
https://cwiki.apache.org/confluence/display/SYNCOPE/[DISCUSS]+Migrate+from+1.2+to+2.0
--
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/
