Re: [DISCUSS] Switching to UUID primary keys for users, groups and any objects

[Francesco Chicchiriccò]

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 
 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/

Re: [DISCUSS] Switching to UUID primary keys for users, groups and any objects

[Guido Wimmel]

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 <
massimiliano.perr...@tirasa.net> 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

Regards.

[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



--
Massimiliano Perrone
Tel +39 393 9121310

Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 085973
http://www.tirasa.net

"L'apprendere molte cose non insegna l'intelligenza"
(Eraclito)

Re: [DISCUSS] Switching to UUID primary keys for users, groups and any objects

[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 <
massimiliano.perr...@tirasa.net> 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
>
> Regards.
>>
>> [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
>>
>>
> --
> Massimiliano Perrone
> Tel +39 393 9121310
>
> Tirasa S.r.l.
> Viale D'Annunzio 267 - 65127 Pescara
> Tel +39 0859116307 / FAX +39 085973
> http://www.tirasa.net
>
> "L'apprendere molte cose non insegna l'intelligenza"
> (Eraclito)
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: [DISCUSS] Switching to UUID primary keys for users, groups and any objects

[Massimiliano Perrone]

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


Regards.

[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



--
Massimiliano Perrone
Tel +39 393 9121310

Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 085973
http://www.tirasa.net

"L'apprendere molte cose non insegna l'intelligenza"
(Eraclito)

Re: [DISCUSS] Switching to UUID primary keys for users, groups and any objects

[Francesco Chicchiriccò]

On 04/04/2016 10:23, Francesco Chicchiriccò wrote:

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.


The mail thread at OpenJPA [6].


WDYT?
Regards.

[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

--
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/

[DISCUSS] Switching to UUID primary keys for users, groups and any objects

[Francesco Chicchiriccò]

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?
Regards.

[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

--
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/