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> 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> wrote:
On Thu, Nov 7, 2013 at 2:40 PM, Lucas Holmquist <lholmqui(a)redhat.com>wrote:
>
> On Nov 7, 2013, at 7:52 AM, Matthias Wessendorf <matzew(a)apache.org>
> wrote:
>
>
>
>
> On Thu, Nov 7, 2013 at 1:20 PM, Erik Jan de Wit <edewit(a)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-Mess...
>
>
https://issues.jboss.org/browse/AGPUSH-86
>
>
>
>>
>> On 7 Nov,2013, at 12:38 , Matthias Wessendorf <matzew(a)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/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