Re: [DISCUSS] Switching to UUID primary keys for users, groups and any objects
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)
[jira] [Commented] (SYNCOPE-806) Validate "standalone" resource provisioning
[
https://issues.apache.org/jira/browse/SYNCOPE-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15224333#comment-15224333
]
Francesco Chicchiriccò commented on SYNCOPE-806:
The actual issue here is that, when defining the mapping for a given
{{AnyType}} A, only attributes defined in A classes are considered by the admin
console; in the case above, the {{USER}} AnyType does not have the {{generic
membership}} AnyTypeClass, where {{postalAddress}} is defined.
The proper fix here is to add, to the {{Provision}} entity the list of
auxiliary classes to be considered with the mapping.
This means that, for the resource {{resource-ldap}} and the AnyType {{USER}},
Syncope will let to optionally specify {{generic membership}} as auxiliary
AnyTypeClass; by consequence, the admin console will include, besides the plain
schemas defined in the class(es) for {{USER}}, the plain schemas defined in
{{generic membership}}, when selecting {{UserPlainSchema}} as internal mapping
type.
> Validate "standalone" resource provisioning
> ---
>
> Key: SYNCOPE-806
> URL: https://issues.apache.org/jira/browse/SYNCOPE-806
> Project: Syncope
> Issue Type: Improvement
> Components: console
>Affects Versions: 2.0.0-M2
>Reporter: Colm O hEigeartaigh
>Assignee: Francesco Chicchiriccò
>Priority: Minor
> Fix For: 2.0.0
>
>
> A lot of the resources configured in the "standalone" distribution appear to
> be missing internal attributes in the provisioning mappings. For example, in
> "resource-ldap" no internal attribute is specified for the mapping to
> "postal". So if you click "Next" on the mapping page you get an error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (SYNCOPE-806) Validate "standalone" resource provisioning
[ https://issues.apache.org/jira/browse/SYNCOPE-806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò reassigned SYNCOPE-806: -- Assignee: Francesco Chicchiriccò > Validate "standalone" resource provisioning > --- > > Key: SYNCOPE-806 > URL: https://issues.apache.org/jira/browse/SYNCOPE-806 > Project: Syncope > Issue Type: Improvement > Components: console >Affects Versions: 2.0.0-M2 >Reporter: Colm O hEigeartaigh >Assignee: Francesco Chicchiriccò >Priority: Minor > Fix For: 2.0.0 > > > A lot of the resources configured in the "standalone" distribution appear to > be missing internal attributes in the provisioning mappings. For example, in > "resource-ldap" no internal attribute is specified for the mapping to > "postal". So if you click "Next" on the mapping page you get an error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SYNCOPE-821) Allow capability override on resources
[ https://issues.apache.org/jira/browse/SYNCOPE-821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15224253#comment-15224253 ] ASF subversion and git services commented on SYNCOPE-821: - Commit bef0726464d8981c8263b29efb89b4d93b173f74 in syncope's branch refs/heads/master from [~ilgrosso] [ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=bef0726 ] [SYNCOPE-821] Implemented > Allow capability override on resources > -- > > Key: SYNCOPE-821 > URL: https://issues.apache.org/jira/browse/SYNCOPE-821 > Project: Syncope > Issue Type: Improvement > Components: console >Reporter: Francesco Chicchiriccò >Assignee: Francesco Chicchiriccò > Fix For: 2.0.0 > > > A given resource might override the capabilities assigned to its underlying > connector; this is not currently specifiable via admin console. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SYNCOPE-821) Allow capability override on resources
[ https://issues.apache.org/jira/browse/SYNCOPE-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò resolved SYNCOPE-821. Resolution: Fixed > Allow capability override on resources > -- > > Key: SYNCOPE-821 > URL: https://issues.apache.org/jira/browse/SYNCOPE-821 > Project: Syncope > Issue Type: Improvement > Components: console >Reporter: Francesco Chicchiriccò >Assignee: Francesco Chicchiriccò > Fix For: 2.0.0 > > > A given resource might override the capabilities assigned to its underlying > connector; this is not currently specifiable via admin console. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [DISCUSS] Switching to UUID primary keys for users, groups and any objects
+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
[jira] [Assigned] (SYNCOPE-821) Allow capability override on resources
[ https://issues.apache.org/jira/browse/SYNCOPE-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò reassigned SYNCOPE-821: -- Assignee: Francesco Chicchiriccò > Allow capability override on resources > -- > > Key: SYNCOPE-821 > URL: https://issues.apache.org/jira/browse/SYNCOPE-821 > Project: Syncope > Issue Type: Improvement > Components: console >Reporter: Francesco Chicchiriccò >Assignee: Francesco Chicchiriccò > Fix For: 2.0.0 > > > A given resource might override the capabilities assigned to its underlying > connector; this is not currently specifiable via admin console. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SYNCOPE-805) Select destination realm from a drop down list when creating a task
[ https://issues.apache.org/jira/browse/SYNCOPE-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò resolved SYNCOPE-805. Resolution: Fixed > Select destination realm from a drop down list when creating a task > --- > > Key: SYNCOPE-805 > URL: https://issues.apache.org/jira/browse/SYNCOPE-805 > Project: Syncope > Issue Type: Improvement > Components: console >Affects Versions: 2.0.0-M2 >Reporter: Colm O hEigeartaigh >Assignee: Francesco Chicchiriccò >Priority: Minor > Fix For: 2.0.0 > > > When creating a (pull) task, if you have to explicitly specify the realm. > However, a better idea would be if the user could select the realm from a > dropdown list. > Incidentally, when currently creating a pull task, if you fail to specify the > realm you get an error message: > org.apache.syncope.common.lib.SyncopeClientException: InvalidPath > [MalformedPathException: Malformed path: null] > This should be updated to let the user know the realm needs to be specified. > But this is probably not required if the user has to select the realm from a > list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SYNCOPE-805) Select destination realm from a drop down list when creating a task
[ https://issues.apache.org/jira/browse/SYNCOPE-805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15224099#comment-15224099 ] ASF subversion and git services commented on SYNCOPE-805: - Commit 323b22cd69b948ef1f742cc2f6d1086d6f8fedec in syncope's branch refs/heads/master from [~ilgrosso] [ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=323b22c ] [SYNCOPE-805] DropDownChoice provided - also set mandatory for PullTasks > Select destination realm from a drop down list when creating a task > --- > > Key: SYNCOPE-805 > URL: https://issues.apache.org/jira/browse/SYNCOPE-805 > Project: Syncope > Issue Type: Improvement > Components: console >Affects Versions: 2.0.0-M2 >Reporter: Colm O hEigeartaigh >Assignee: Francesco Chicchiriccò >Priority: Minor > Fix For: 2.0.0 > > > When creating a (pull) task, if you have to explicitly specify the realm. > However, a better idea would be if the user could select the realm from a > dropdown list. > Incidentally, when currently creating a pull task, if you fail to specify the > realm you get an error message: > org.apache.syncope.common.lib.SyncopeClientException: InvalidPath > [MalformedPathException: Malformed path: null] > This should be updated to let the user know the realm needs to be specified. > But this is probably not required if the user has to select the realm from a > list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SYNCOPE-805) Select destination realm from a drop down list when creating a task
[ https://issues.apache.org/jira/browse/SYNCOPE-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò reassigned SYNCOPE-805: -- Assignee: Francesco Chicchiriccò > Select destination realm from a drop down list when creating a task > --- > > Key: SYNCOPE-805 > URL: https://issues.apache.org/jira/browse/SYNCOPE-805 > Project: Syncope > Issue Type: Improvement > Components: console >Affects Versions: 2.0.0-M2 >Reporter: Colm O hEigeartaigh >Assignee: Francesco Chicchiriccò >Priority: Minor > Fix For: 2.0.0 > > > When creating a (pull) task, if you have to explicitly specify the realm. > However, a better idea would be if the user could select the realm from a > dropdown list. > Incidentally, when currently creating a pull task, if you fail to specify the > realm you get an error message: > org.apache.syncope.common.lib.SyncopeClientException: InvalidPath > [MalformedPathException: Malformed path: null] > This should be updated to let the user know the realm needs to be specified. > But this is probably not required if the user has to select the realm from a > list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SYNCOPE-793) Password" keys missing when creating a resource mapping
[ https://issues.apache.org/jira/browse/SYNCOPE-793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò resolved SYNCOPE-793. Resolution: Fixed > Password" keys missing when creating a resource mapping > --- > > Key: SYNCOPE-793 > URL: https://issues.apache.org/jira/browse/SYNCOPE-793 > Project: Syncope > Issue Type: Bug > Components: console >Affects Versions: 2.0.0-M2 >Reporter: Colm O hEigeartaigh >Assignee: Francesco Chicchiriccò >Priority: Minor > Fix For: 2.0.0 > > Attachments: syncope-resource.png > > > When creating a new resource mapping, the UI displays "ConnObjectKey" over > the first checkbox. However, there is no "title" associated with the > "Password" checkbox. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SYNCOPE-793) Password" keys missing when creating a resource mapping
[ https://issues.apache.org/jira/browse/SYNCOPE-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15224049#comment-15224049 ] ASF subversion and git services commented on SYNCOPE-793: - Commit 74e57f1f732728ab0ca622239960207b948fe879 in syncope's branch refs/heads/master from [~ilgrosso] [ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=74e57f1 ] [SYNCOPE-793] Fixed by overriding ResourceMappingPanel#onBeforeRender > Password" keys missing when creating a resource mapping > --- > > Key: SYNCOPE-793 > URL: https://issues.apache.org/jira/browse/SYNCOPE-793 > Project: Syncope > Issue Type: Bug > Components: console >Affects Versions: 2.0.0-M2 >Reporter: Colm O hEigeartaigh >Assignee: Francesco Chicchiriccò >Priority: Minor > Fix For: 2.0.0 > > Attachments: syncope-resource.png > > > When creating a new resource mapping, the UI displays "ConnObjectKey" over > the first checkbox. However, there is no "title" associated with the > "Password" checkbox. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SYNCOPE-793) Password" keys missing when creating a resource mapping
[ https://issues.apache.org/jira/browse/SYNCOPE-793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò reassigned SYNCOPE-793: -- Assignee: Francesco Chicchiriccò > Password" keys missing when creating a resource mapping > --- > > Key: SYNCOPE-793 > URL: https://issues.apache.org/jira/browse/SYNCOPE-793 > Project: Syncope > Issue Type: Bug > Components: console >Affects Versions: 2.0.0-M2 >Reporter: Colm O hEigeartaigh >Assignee: Francesco Chicchiriccò >Priority: Minor > Fix For: 2.0.0 > > Attachments: syncope-resource.png > > > When creating a new resource mapping, the UI displays "ConnObjectKey" over > the first checkbox. However, there is no "title" associated with the > "Password" checkbox. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SYNCOPE-811) Error message "'spinner' is required"
[
https://issues.apache.org/jira/browse/SYNCOPE-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò resolved SYNCOPE-811.
Resolution: Fixed
> Error message "'spinner' is required"
> -
>
> Key: SYNCOPE-811
> URL: https://issues.apache.org/jira/browse/SYNCOPE-811
> Project: Syncope
> Issue Type: Bug
> Components: console
>Affects Versions: 2.0.0-M2
>Reporter: Colm O hEigeartaigh
>Assignee: Francesco Chicchiriccò
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: syncope-spinner.png
>
>
> If you don't specify a value when configuring an any object for a required
> {{Long}} or {{Double}} schema, you get a generic error message "'spinner' is
> required". Instead, the error message should display the name of the schema.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SYNCOPE-811) Error message "'spinner' is required"
[
https://issues.apache.org/jira/browse/SYNCOPE-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223978#comment-15223978
]
ASF subversion and git services commented on SYNCOPE-811:
-
Commit 45bfdf7de9e7d0a17d2d59ce43be05ca3c94b968 in syncope's branch
refs/heads/master from [~ilgrosso]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=45bfdf7 ]
[SYNCOPE-811] Fixed
> Error message "'spinner' is required"
> -
>
> Key: SYNCOPE-811
> URL: https://issues.apache.org/jira/browse/SYNCOPE-811
> Project: Syncope
> Issue Type: Bug
> Components: console
>Affects Versions: 2.0.0-M2
>Reporter: Colm O hEigeartaigh
>Assignee: Francesco Chicchiriccò
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: syncope-spinner.png
>
>
> If you don't specify a value when configuring an any object for a required
> {{Long}} or {{Double}} schema, you get a generic error message "'spinner' is
> required". Instead, the error message should display the name of the schema.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (SYNCOPE-811) Error message "'spinner' is required"
[
https://issues.apache.org/jira/browse/SYNCOPE-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò reassigned SYNCOPE-811:
--
Assignee: Francesco Chicchiriccò
> Error message "'spinner' is required"
> -
>
> Key: SYNCOPE-811
> URL: https://issues.apache.org/jira/browse/SYNCOPE-811
> Project: Syncope
> Issue Type: Bug
> Components: console
>Affects Versions: 2.0.0-M2
>Reporter: Colm O hEigeartaigh
>Assignee: Francesco Chicchiriccò
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: syncope-spinner.png
>
>
> If you don't specify a value when configuring an any object for a required
> {{Long}} or {{Double}} schema, you get a generic error message "'spinner' is
> required". Instead, the error message should display the name of the schema.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [DISCUSS] Switching to UUID primary keys for users, groups and any objects
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)
[jira] [Commented] (SYNCOPE-804) Support the explanation of the Connector Configuration properties
[ https://issues.apache.org/jira/browse/SYNCOPE-804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223890#comment-15223890 ] ASF subversion and git services commented on SYNCOPE-804: - Commit 7857936e65328ab8d2b4d7753cde7dac1abf6ae1 in syncope's branch refs/heads/master from [~ilgrosso] [ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=7857936 ] [SYNCOPE-804] Using popover insted of plain title > Support the explanation of the Connector Configuration properties > - > > Key: SYNCOPE-804 > URL: https://issues.apache.org/jira/browse/SYNCOPE-804 > Project: Syncope > Issue Type: Improvement > Components: console >Affects Versions: 1.2.7, 2.0.0-M2 >Reporter: Colm O hEigeartaigh >Assignee: Francesco Chicchiriccò >Priority: Minor > Fix For: 1.2.8, 2.0.0 > > Attachments: screen2.png > > > In previous Syncope versions, one could hover over the textfields when > configuring Connector properties, and get an explanation as to what the > configuration item meant. However this is not working in the latest release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [DISCUSS] Switching to UUID primary keys for users, groups and any objects
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
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/
