[aerogear-dev] [UnifiedPush] PushApplication/Variant ID and PK generation
Matthias Wessendorf
matzew at apache.org
Thu Nov 7 12:27:09 EST 2013
point taken
On Thu, Nov 7, 2013 at 5:35 PM, Apostolos Emmanouilidis <aemmanou at 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 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 listaerogear-dev at lists.jboss.orghttps://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131107/64c017c0/attachment-0001.html
More information about the aerogear-dev
mailing list