+1 we can do without the hibernate dependency, making the code more portable. One question it does raise, is why are UUID used as keys? And if a class like PushApplication already has a UUID why would it need another UUID for a key?

On 7 Nov,2013, at 12:38 , Matthias Wessendorf <matzew(a)apache.org&gt; wrote: Hello, today the PushApplicationID ([1]) and VariantID (iOS example: [2]) are generated w/in the RESTful endpoint class. I'd like to move that into the actual entity - similar to what we today already do with the (master)secret (e.g. [3] or [4]). Thoughts? While on it - I'd like to do similar to the PK all ALL entities... Today we have an (odd) Hibernate dependency (see [5]), simple b/c of JPA being lame and not providing "propper" UUID support.... So idea is to * remove the odd annotation * do the ID generation "by hand" (like we do on the secret (see above...)) Thoughts? Sure, this (both items of this mail) might lead to some more re-usable code (and better tests) -Matthias [1] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... [2] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... [3] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... [4] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... [5] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Nov 7, 2013, at 7:52 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Thu, Nov 7, 2013 at 1:20 PM, Erik Jan de Wit <edewit(a)redhat.com&gt; wrote: > +1 we can do without the hibernate dependency, making the code more > portable. One question it does raise, is why are UUID used as keys? And if > a class like PushApplication already has a UUID why would it need > another UUID for a key? > primaryKey (database) variant/pushAPP ID (semantic meaning) A while ago we decided to NOT use the PK as the variant/pushAPP ID; let me see if I can find the JIRA/thread here is where i brought this up http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-AeroGear-Push-Mess...

> > On 7 Nov,2013, at 12:38 , Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > Hello, > > today the PushApplicationID ([1]) and VariantID (iOS example: [2]) are > generated w/in the RESTful endpoint class. I'd like to move that into the > actual entity - similar to what we today already do with the (master)secret > (e.g. [3] or [4]). > > Thoughts? > > > While on it - I'd like to do similar to the PK all ALL entities... Today > we have an (odd) Hibernate dependency (see [5]), simple b/c of JPA being > lame and not providing "propper" UUID support.... So idea is to > * remove the odd annotation > * do the ID generation "by hand" (like we do on the secret (see above...)) > > Thoughts? > > Sure, this (both items of this mail) might lead to some more re-usable > code (and better tests) > > > -Matthias > > > [1] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... > [2] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... > [3] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... > [4] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... > [5] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Don't get me wrong I know it's good practice to use a surrogate key instead of a natural one, but why does the key need to be a UUID? Seems that it's a bit big and a sequence would do just as nicely. Then we don't need this 'workaround' creating the keys by 'hand'. Because the 'workaround' does have a problem, when would we create the id? Hibernate will 'normally' use null as a value for the id to see that it's a new entity and preforms an insert. But maybe hibernate is smart enough, because you could also use primitives for keys although that is not recommended. Anyway that is why I suggest let's keep it simple and use a Long for the id On 7 Nov,2013, at 14:48 , Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > > > > On Thu, Nov 7, 2013 at 2:40 PM, Lucas Holmquist > <lholmqui(a)redhat.com&gt; wrote: > > > > On Nov 7, 2013, at 7:52 AM, Matthias Wessendorf > <matzew(a)apache.org&gt; wrote: > > > > > > > > > > > > > > > On Thu, Nov 7, 2013 at 1:20 PM, Erik Jan de Wit > > <edewit(a)redhat.com&gt; wrote: > > > > +1 we can do without the hibernate dependency, > > making the code more portable. One question it > > does raise, is why are UUID used as keys? And if a > > class like PushApplication already has a UUID why > > would it need another UUID for a key? > > > > > > primaryKey (database) > > variant/pushAPP ID (semantic meaning) > > > > > > A while ago we decided to NOT use the PK as the > > variant/pushAPP ID; let me see if I can find the > > JIRA/thread > > > here is where i brought this up > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-AeroGear-Push-Mess... > > > > > https://issues.jboss.org/browse/AGPUSH-86 > > > > > > > > > > > > > > > > > > On 7 Nov,2013, at 12:38 , Matthias Wessendorf > > <matzew(a)apache.org&gt; wrote: > > > > > > > > > Hello, > > > > > > > > > > > > today the PushApplicationID ([1]) and VariantID > > > (iOS example: [2]) are generated w/in the > > > RESTful endpoint class. I'd like to move that > > > into the actual entity - similar to what we > > > today already do with the (master)secret (e.g. > > > [3] or [4]). > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > While on it - I'd like to do similar to the PK > > > all ALL entities... Today we have an (odd) > > > Hibernate dependency (see [5]), simple b/c of > > > JPA being lame and not providing "propper" UUID > > > support.... So idea is to > > > * remove the odd annotation > > > * do the ID generation "by hand" (like we do on > > > the secret (see above...)) > > > > > > > > > Thoughts? > > > > > > > > > > > > Sure, this (both items of this mail) might lead > > > to some more re-usable code (and better tests) > > > > > > > > > > > > > > > -Matthias > > > > > > > > > > > > > > > [1] > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... > > > [2] > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... > > > [3] > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... > > > [4] > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... > > > [5] > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... > > > > > > > > > > > > -- > > > Matthias Wessendorf > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > sessions: http://www.slideshare.net/mwessendorf > > > twitter: http://twitter.com/mwessendorf > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Don't get me wrong I know it's good practice to use a surrogate key instead of a natural one, but why does the key need to be a UUID? Seems that it's a bit big and a sequence would do just as nicely. Then we don't need this 'workaround' creating the keys by 'hand'. Because the 'workaround' does have a problem, when would we create the id? Hibernate will 'normally' use null as a value for the id to see that it's a new entity and preforms an insert. But maybe hibernate is smart enough, because you could also use primitives for keys although that is not recommended. Anyway that is why I suggest let's keep it simple and use a Long for the id On 7 Nov,2013, at 14:48 , Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Thu, Nov 7, 2013 at 2:40 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;wrote: > > On Nov 7, 2013, at 7:52 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > > > > On Thu, Nov 7, 2013 at 1:20 PM, Erik Jan de Wit <edewit(a)redhat.com&gt;wrote: > >> +1 we can do without the hibernate dependency, making the code more >> portable. One question it does raise, is why are UUID used as keys? And if >> a class like PushApplication already has a UUID why would it need >> another UUID for a key? >> > > primaryKey (database) > variant/pushAPP ID (semantic meaning) > > A while ago we decided to NOT use the PK as the variant/pushAPP ID; let > me see if I can find the JIRA/thread > > > here is where i brought this up > > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-AeroGear-Push-Mess... > > https://issues.jboss.org/browse/AGPUSH-86 > > > >> >> On 7 Nov,2013, at 12:38 , Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >> Hello, >> >> today the PushApplicationID ([1]) and VariantID (iOS example: [2]) are >> generated w/in the RESTful endpoint class. I'd like to move that into the >> actual entity - similar to what we today already do with the (master)secret >> (e.g. [3] or [4]). >> >> Thoughts? >> >> >> While on it - I'd like to do similar to the PK all ALL entities... Today >> we have an (odd) Hibernate dependency (see [5]), simple b/c of JPA being >> lame and not providing "propper" UUID support.... So idea is to >> * remove the odd annotation >> * do the ID generation "by hand" (like we do on the secret (see >> above...)) >> >> Thoughts? >> >> Sure, this (both items of this mail) might lead to some more re-usable >> code (and better tests) >> >> >> -Matthias >> >> >> [1] >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... >> [2] >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... >> [3] >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... >> [4] >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... >> [5] >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Right that is what I mean On 7 Nov,2013, at 18:26 , Matthias Wessendorf <matzew(a)apache.org&gt; wrote: yep, all that is right. Background: we did abuse the PK as the application/variantID, hence something like a UUID was needed - as a 1,2,3,and so on would have been odd; Now, that we have application/variantID and the PK really has no other meaning, I guess using something like the following is OK: @Id @GeneratedValue(strategy = GenerationType.AUTO) private String/Long id; That's what you had in mind, right ? -Matthias On Thu, Nov 7, 2013 at 4:16 PM, Erik Jan de Wit <edewit(a)redhat.com&gt; wrote: > Don't get me wrong I know it's good practice to use a surrogate key > instead of a natural one, but why does the key need to be a UUID? Seems > that it's a bit big and a sequence would do just as nicely. Then we don't > need this 'workaround' creating the keys by 'hand'. > > Because the 'workaround' does have a problem, when would we create the > id? Hibernate will 'normally' use null as a value for the id to see that > it's a new entity and preforms an insert. But maybe hibernate is smart > enough, because you could also use primitives for keys although that is not > recommended. > > Anyway that is why I suggest let's keep it simple and use a Long for the > id > > On 7 Nov,2013, at 14:48 , Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > > > On Thu, Nov 7, 2013 at 2:40 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;wrote: > >> >> On Nov 7, 2013, at 7:52 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >> >> >> >> On Thu, Nov 7, 2013 at 1:20 PM, Erik Jan de Wit <edewit(a)redhat.com&gt;wrote: >> >>> +1 we can do without the hibernate dependency, making the code more >>> portable. One question it does raise, is why are UUID used as keys? And if >>> a class like PushApplication already has a UUID why would it need >>> another UUID for a key? >>> >> >> primaryKey (database) >> variant/pushAPP ID (semantic meaning) >> >> A while ago we decided to NOT use the PK as the variant/pushAPP ID; let >> me see if I can find the JIRA/thread >> >> >> here is where i brought this up >> >> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-AeroGear-Push-Mess... >> >> > https://issues.jboss.org/browse/AGPUSH-86 > > > > >> >> >> >>> >>> On 7 Nov,2013, at 12:38 , Matthias Wessendorf <matzew(a)apache.org&gt; >>> wrote: >>> >>> Hello, >>> >>> today the PushApplicationID ([1]) and VariantID (iOS example: [2]) are >>> generated w/in the RESTful endpoint class. I'd like to move that into the >>> actual entity - similar to what we today already do with the (master)secret >>> (e.g. [3] or [4]). >>> >>> Thoughts? >>> >>> >>> While on it - I'd like to do similar to the PK all ALL entities... >>> Today we have an (odd) Hibernate dependency (see [5]), simple b/c of JPA >>> being lame and not providing "propper" UUID support.... So idea is to >>> * remove the odd annotation >>> * do the ID generation "by hand" (like we do on the secret (see >>> above...)) >>> >>> Thoughts? >>> >>> Sure, this (both items of this mail) might lead to some more re-usable >>> code (and better tests) >>> >>> >>> -Matthias >>> >>> >>> [1] >>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... >>> [2] >>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... >>> [3] >>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... >>> [4] >>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... >>> [5] >>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

wrote:

+1 ID generation by hand provides more flexibility. btw the same result could be achieved by using uuid2 generator instead of uuid which is currently used and org.hibernate.id.uuid.StandardRandomStrategy. This way the UUID values are produced using java.util.UUID randomUUID. but I agree that removing odd annotations is a good idea

On Thu, 2013-11-07 at 12:38 +0100, Matthias Wessendorf wrote: Hello, today the PushApplicationID ([1]) and VariantID (iOS example: [2]) are generated w/in the RESTful endpoint class. I'd like to move that into the actual entity - similar to what we today already do with the (master)secret (e.g. [3] or [4]). Thoughts? While on it - I'd like to do similar to the PK all ALL entities... Today we have an (odd) Hibernate dependency (see [5]), simple b/c of JPA being lame and not providing "propper" UUID support.... So idea is to * remove the odd annotation * do the ID generation "by hand" (like we do on the secret (see above...)) Thoughts? Sure, this (both items of this mail) might lead to some more re-usable code (and better tests) -Matthias [1] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... [2] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... [3] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... [4] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... [5] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/m... -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev