Re: [aerogear-dev] [UnifiedPush] PushApplication/Variant ID and PK generation

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