continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <ja...@maven.org>
Subject Re: short term branch for project/group keys
Date Sat, 23 Dec 2006 14:38:33 GMT

On 22 Dec 06, at 11:48 AM 22 Dec 06, Jesse McConnell wrote:

> nope, no fundamental reasons behind the immutable bit on the keys, I
> am cool with them being open for editing.
>

I think they are immutable so when links are created with them they  
don't just disappear.

Jason.

> 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