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: short term branch for project/group keys
Date Fri, 22 Dec 2006 18:17:42 GMT
project keys are not unique, you need the group key and project key
together to get the actual summary.

it should be fine in the store since the index is the uniqifying
bit..the project class will need a group key in it as well to make
that work

a couple of other things came up today so I haven't started that
branch yet but hopefully soon as I clear off a couple of things now.

jesse

On 12/22/06, Rahul Thakur <rahul.thakur.xdev@gmail.com> wrote:
> So, if we have 2 sessions using the same project as target
>
> - user A opens up some Project X's summary for viewing
> - user B updates Project X's string key to Y.
>
> Wouldn't that invalidate the key values being used by user A's session?
> How will this be handled?
>
> Cheers,
> Rahul
>
> ----- Original Message -----
> From: "Jesse McConnell" <jesse.mcconnell@gmail.com>
> To: <continuum-dev@maven.apache.org>
> Sent: Saturday, December 23, 2006 6:48 AM
> Subject: Re: short term branch for project/group keys
>
>
> > nope, no fundamental reasons behind the immutable bit on the keys, I
> > am cool with them being open for editing.
> >
> > jesse
> >
> > On 12/22/06, Christian Edward Gruber <cgruber@israfil.net> wrote:
> >> This all sounds great, but why do they need to be immutable?  If they
> >> are essentially used for lookups, and they only exist in one place in
> >> the database (because it's normalized enough through surrogate keys),
> >> then other then the obvious caveats about external things depending
> >> on
> >> the keys, why couldn't these string keys change?  There should be no
> >> referential integrity issues, because these keys are not the subjects
> >> of
> >> any joins - just where clauses from the interfaces.
> >>
> >> This would include project.key, group.key, buildDef.key,
> >> notifier.key,
> >> etc.  It could even apply to userId, though standard practice is that
> >> usernames are immutable.  All the other "lookup keys" could quite
> >> easily
> >> be mutable/re-nameable if we wished.  Am I missing something?  I can
> >> certainly see the usefulness of being able to, for maintenance of the
> >> continuum instance.  Not strictly necessary, but saves several steps.
> >>
> >> Christian.
> >>
> >> Jesse McConnell wrote:
> >> > On 12/22/06, Brett Porter <brett@apache.org> wrote:
> >> >> Sounds good, as long as the store remains independent of them. I
> >> >> don't want to get into the situation like in JIRA where you can't
> >> >> rename a string key.
> >> >
> >> > Yes, jason pinged me on this since I guess I wasn't completely
> >> > clear
> >> > in that summary.
> >> >
> >> > the project.id and projectGroup.id will basically disappear from
> >> > continuum, reserved strictly for the underlying store.  The store
> >> > can
> >> > do whatever it wants with them.  The UI will never pass around a
> >> > projectId=26 param on a url making you wonder what the heck it was.
> >> > A
> >> > nice side effect of this IMO is that the #'s in the working
> >> > directory
> >> > would go away as well, defaulting instead to a nested directory
> >> > structure of workingDirectory/GroupKey/ProjectKey/pom.xml
> >> >
> >> > Now I had honestly been thinking of making the key's immutable,
> >> > since
> >> > the names of the group's and project's are to be used for all
> >> > presentational type things.  I was going to treat keys under the
> >> > same
> >> > functional requirements that usernames generally have.  Maybe we
> >> > offer
> >> > a 'Clone' option that makes a deep copy of the data in the DB into
> >> > a
> >> > new name and then allow the deletion of the old one...
> >> >
> >> > Anyway, here are the restrictions I thought of placing on the keys.
> >> >
> >> > * [a-zA-Z1-9.-:] for all keys
> >> > * group key is unique
> >> > * group key + project key is unique
> >> > * project key should _not_ need to be unique  (ex Doxia/Core +
> >> > Maven/Core + Continuum/Core)
> >> > * keys are immutable, set upon creation
> >> >
> >> >> Before starting to hack on this, perhaps you could list out all
> >> >> the
> >> >> keys you think are needed, and some examples? I'm interested in
> >> >> how
> >> >> it relates to group IDs and artifact IDs in particular.
> >> >
> >> > Initially I was planning on doing just the project key and group
> >> > key
> >> > since there is so much involved with getting just those two in
> >> > place.
> >> > However everything would probably go that way so that Profiles,
> >> > Schedules, BuildDefinitions, etc...anything with an int ID that is
> >> > used around in continuum would be converted to use a strongly typed
> >> > string key instead....the ones other then project and group are
> >> > less
> >> > important in the short term since they are not a constant source of
> >> > confusion...but eventually yes anything with and ID would get a Key
> >> > like this.  If the branch is a success and is voted back onto trunk
> >> > then those could take place on trunk I think since they are smaller
> >> > scope.
> >> >
> >> > As for how they would relate to groupId's and artifactId's it was
> >> > not
> >> > my intent to deal with those at all.  One of the things that got us
> >> > into the mess that currently exists was too great a focus on the m2
> >> > side of continuum.  IMO the group and project keys should be kept
> >> > external to any concept of project type.  That way we can always
> >> > maintain a clear delineation between a group and its member
> >> > projects
> >> > in relation to other groups.  For instance, one of my goals here is
> >> > to
> >> > make it super easy to have multiple versions of Doxia load up in
> >> > continuum and execute in their little sandboxes.
> >> > Group Keys of Doxia and Doxia-Refactor (just an example branch)
> >> > should
> >> > be able to seamlessly import the doxia project from its relative
> >> > sources and peacefully coexist.  And it should be just as easy to
> >> > do
> >> > the same with a number of ant, shell and maven1 projects.
> >> >
> >> > Anyway, some foreseeable real world example keys in one continuum
> >> > instance:
> >> >
> >> > Group:
> >> >  Maven-Trunk
> >> > Projects:
> >> >  Core
> >> >  Api
> >> >  Artfiact
> >> >
> >> > Group:
> >> >  Maven-2.0.5
> >> > Projects:
> >> >  Core
> >> >  Api
> >> >  Artifact
> >> >
> >> > Group:
> >> >  Continuum
> >> > Projects:
> >> >  Core
> >> >  Api
> >> >  Store
> >> >  Webapp
> >> >
> >> > cheers,
> >> >
> >> > jesse
> >> >
> >> >
> >> >> - Brett
> >> >>
> >> >> On 22/12/2006, at 6:30 AM, Jesse McConnell wrote:
> >> >>
> >> >> > I am thinking about pulling a short term branch of continuum
> >> >> > with
> >> >> > rahul and working on getting everything converted to using a
> >> >> > string
> >> >> > based key project and project group reference in all apis and
in
> >> >> > all
> >> >> > of the UI decision making items.  He has tomorrow off so I think
> >> >> > that
> >> >> > unless anyone has any big issues with it we'll try and make that
> >> >> > branch and work on it tomorrow.
> >> >> >
> >> >> > the end result of it would be:
> >> >> >
> >> >> > * int id's for project and project group in the model are for
> >> >> > internal
> >> >> > store usage
> >> >> > * name's for project and project group are for presentation
> >> >> > purposes only
> >> >> > * key's are for all api usage and passing around un URL's etc.
> >> >> >
> >> >> > some quick benefits are:
> >> >> >
> >> >> > * consistency across all apis and url manipulations
> >> >> > * ability to add quick url rewriting for direct linking of
> >> >> > projects
> >> >> > foo.org/Doxia/Core
> >> >> > * common keys across running continuum instances for clustering
> >> >> >
> >> >> > jesse
> >> >> >
> >> >> > --
> >> >> > jesse mcconnell
> >> >> > jesse.mcconnell@gmail.com
> >> >>
> >> >
> >> >
> >>
> >>
> >> --
> >>
> >> *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
>
>


-- 
jesse mcconnell
jesse.mcconnell@gmail.com

Mime
View raw message