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

Erik Jan de Wit edewit at redhat.com
Thu Nov 7 10:16:26 EST 2013


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 at apache.org> wrote:

> 
> 
> 
> On Thu, Nov 7, 2013 at 2:40 PM, Lucas Holmquist <lholmqui at redhat.com> wrote:
> 
> On Nov 7, 2013, at 7:52 AM, Matthias Wessendorf <matzew at apache.org> wrote:
> 
>> 
>> 
>> 
>> On Thu, Nov 7, 2013 at 1:20 PM, Erik Jan de Wit <edewit at redhat.com> 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-Message-Format-tp2773p2905.html
> 
> 
> https://issues.jboss.org/browse/AGPUSH-86
> 
> 
>  
> 
>>  
>> 
>> On 7 Nov,2013, at 12:38 , Matthias Wessendorf <matzew at apache.org> 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/main/java/org/jboss/aerogear/unifiedpush/rest/registry/applications/PushApplicationEndpoint.java#L76
>>> [2] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/applications/iOSVariantEndpoint.java#L105
>>> [3] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/main/java/org/jboss/aerogear/unifiedpush/model/PushApplication.java#L38
>>> [4] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/main/java/org/jboss/aerogear/unifiedpush/model/AbstractVariant.java#L49
>>> [5] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/main/java/org/jboss/aerogear/unifiedpush/jpa/PersistentObject.java#L34
>>> 
>>> -- 
>>> Matthias Wessendorf 
>>> 
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> 
>> 
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131107/b2f48dfc/attachment.html 


More information about the aerogear-dev mailing list