Right that is what I mean

On 7 Nov,2013, at 18:26 , Matthias Wessendorf <matzew@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@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@apache.org> wrote:




On Thu, Nov 7, 2013 at 2:40 PM, Lucas Holmquist <lholmqui@redhat.com> wrote:

On Nov 7, 2013, at 7:52 AM, Matthias Wessendorf <matzew@apache.org> wrote:




On Thu, Nov 7, 2013 at 1:20 PM, Erik Jan de Wit <edewit@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 




 

 

On 7 Nov,2013, at 12:38 , Matthias Wessendorf <matzew@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



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev