+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?
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