[aerogear-dev] [UnifiedPush] PushApplication/Variant ID and PK generation
Apostolos Emmanouilidis
aemmanou at redhat.com
Thu Nov 7 11:35:56 EST 2013
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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131107/2989a0a2/attachment-0001.html
More information about the aerogear-dev
mailing list