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 17:48:04 GMT
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

Mime
View raw message