12:38 p.m.
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
1:20 p.m.
+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
1:52 p.m.
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
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
1:55 p.m.
+1 ID generation by hand provides more flexibility.
btw the same result could be achieved by using uuid2 generator instead
of uuid which is currently used and
org.hibernate.id.uuid.StandardRandomStrategy. This way the UUID values
are produced using java.util.UUID randomUUID. but I agree that removing
odd annotations is a good idea
On Thu, 2013-11-07 at 12:38 +0100, Matthias Wessendorf 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
1:57 p.m.
On Thu, Nov 7, 2013 at 1:55 PM, Apostolos Emmanouilidis <aemmanou(a)redhat.com
wrote:
+1 ID generation by hand provides more flexibility.
btw the same result could be achieved by using uuid2 generator instead of
uuid which is currently used and
org.hibernate.id.uuid.StandardRandomStrategy. This way the UUID values are
produced using java.util.UUID randomUUID. but I agree that removing odd
annotations is a good idea
that is not portable to other JPA implementations, right ?
On Thu, 2013-11-07 at 12:38 +0100, Matthias Wessendorf 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
listaerogear-dev@lists.jboss.orghttps://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
2:06 p.m.
On Thu, 2013-11-07 at 13:57 +0100, Matthias Wessendorf wrote:
On Thu, Nov 7, 2013 at 1:55 PM, Apostolos Emmanouilidis
<aemmanou(a)redhat.com> wrote:
+1 ID generation by hand provides more flexibility.
btw the same result could be achieved by using uuid2 generator
instead of uuid which is currently used and
org.hibernate.id.uuid.StandardRandomStrategy. This way the
UUID values are produced using java.util.UUID randomUUID. but
I agree that removing odd annotations is a good idea
that is not portable to other JPA implementations, right ?
now I see that org.hibernate.annotations.GenericGenerator is the only
dependency on Hibernate, inside ag-ups source code
good point, +1 for removing it
On Thu, 2013-11-07 at 12:38 +0100, Matthias Wessendorf 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
2:40 p.m.
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...
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
2:48 p.m.
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
4:16 p.m.
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
5:35 p.m.
I consider using UUID as a better choice from a design point of view. If
two companies are using UPS and they get merged, the data stored in UPS
dbs has to be merged as well. If sequences are used, this task will be a
big pain due to the conflicts. However it will be much easier if UUIDs
are used. In addition UUID are more flexible when scaling. I'm not sure
what happens from a performance point of view.
On Thu, 2013-11-07 at 16:16 +0100, Erik Jan de Wit 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
6:26 p.m.
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
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
6:27 p.m.
point taken
On Thu, Nov 7, 2013 at 5:35 PM, Apostolos Emmanouilidis <aemmanou(a)redhat.com
wrote:
> I consider using UUID as a better choice from a design point of view. If
> two companies are using UPS and they get merged, the data stored in UPS dbs
> has to be merged as well. If sequences are used, this task will be a big
> pain due to the conflicts. However it will be much easier if UUIDs are
> used. In addition UUID are more flexible when scaling. I'm not sure what
> happens from a performance point of view.
>
>
> On Thu, 2013-11-07 at 16:16 +0100, Erik Jan de Wit 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
listaerogear-dev@lists.jboss.orghttps://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
8:31 a.m.
Right that is what I mean
On 7 Nov,2013, at 18:26 , Matthias Wessendorf <matzew(a)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(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
--
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
8:34 a.m.
Not sure, but I like the UUID ;)
On Nov 8, 2013 8:32 AM, "Erik Jan de Wit" <edewit(a)redhat.com> wrote:
Right that is what I mean
On 7 Nov,2013, at 18:26 , Matthias Wessendorf <matzew(a)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(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
>
--
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
3830
days inactive
3831
days old
13 comments
4 participants
participants (4)
-
Apostolos Emmanouilidis -
Erik Jan de Wit -
Lucas Holmquist -
Matthias Wessendorf