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

Fri Nov 8 02:34:11 EST 2013

Not sure, but I like the UUID ;)
On Nov 8, 2013 8:32 AM, "Erik Jan de Wit" <edewit at redhat.com> wrote:

> Right that is what I mean
>
> On 7 Nov,2013, at 18:26 , Matthias Wessendorf <matzew at apache.org> 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 at redhat.com> 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 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
>>
>>
>>
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131108/300afb1b/attachment.html 