continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse McConnell" <jesse.mcconn...@gmail.com>
Subject Re: project group shortcuts
Date Sat, 04 Nov 2006 20:33:06 GMT
I am not actually referring to anything about how they are stored in
the database, that is purely integer keys in the jdo store in in this
case, the projects are logically stored in the group object that is
persisted into whatever store.

I am referring to how you programmatically refer to them, to access
the group you ask for it by the string groupId, to get a particular
project you need to know the group id it is in and then the string
projectId of that project.  right now it is possible to get the
project instance directly by knowing the integer id of that project
which is currently that internal jdo index number.

this would be so that you could have two instance of a project group
loaded up and maintain the same projectIds for the same projects in
those groups, and then distinguish between them by the group they are
a member of.  this is because I think it would be annoying as sin to
load up Doxia and make a DoxiaCore project in it, and then load up a
DoxiaBranchFoo and have to name the DoxiaCore something like
DoxiaCoreBranch just to make it unique.

is that clearer?

jesse

p.s. great feedback, thanks


On 11/4/06, Christian Edward Gruber <cgruber@israfil.net> wrote:
> Cool,  more comment in-line.
>
> Jesse McConnell wrote:
> > On 11/4/06, Christian Edward Gruber <cgruber@israfil.net> wrote:
> >> To that end, also, I think that the projects should still have an
> >> internal primary key that's integer based, but that (continuum)
> >> groupId+projectId should be an alternate "business key" for the
> >> integerId.  This, of course, to avoid craziness between multiple copies
> >> of project groups.
> >
> > right, the Project already has an id which is integer and is the store
> > key for that object, I am proposing here that we stop using these
> > internal store id's all over the place in the UI and other code.  and
> > your right, groupId + projectId (the string short names) would be the
> > business key for this, they would together be unique always.  I think
> > projectId could be shared across multiple groups though, so to get a
> > particular one of those you would need to know the groupId to get it
> > from.
> Meh.  I'm not a fan of compound-primary-keys, except on join tables, or
> when you really have to.  If these projectIds are surrogate keys, then
> they should be unique, with a foreign-key to groupId to maintain the
> strong relationship.  Joins get torturous (and more expensive) when you
> have compound primary keys, and the further out your join-tables, the
> more times you replicate several keys.  If we're separating surrogate
> keys from business keys, then let's keep single unique surrogate keys as
> primary keys, and leave the composite stuff for business keys.  Just my
> opinionated view... :)
>
> Christian
> --
>
> *christian** gruber + process coach and architect*
>
> *Israfil Consulting Services Corporation*
>
> *email** cgruber@israfil.net + bus 905.640.1119 + mob 416.998.6023*
>
>
>


-- 
jesse mcconnell
jesse.mcconnell@gmail.com

Mime
View raw message