Mailing-List: contact continuum-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: continuum-dev@maven.apache.org
Received-SPF: neutral (herse.apache.org: 210.54.141.242 is neither permitted
 nor denied by domain of rahul.thakur.xdev@gmail.com)
Message-ID: <001401c725f4$c8247970$4001a8c0@nonec03d6244ff>
From: "Rahul Thakur" <rahul.thakur.xdev@gmail.com>
To: <continuum-dev@maven.apache.org>
References: <a43524d00612211130q64d98545v349e20547d865e73@mail.gmail.com>
 <36FDE11F-5D15-4158-927A-36550539B00C@apache.org>
 <a43524d00612220524w15e94c86md20d6740c0431cf4@mail.gmail.com>
 <458BFF48.4040003@israfil.net>
 <a43524d00612220948u5c1001aeg1af3baf47054b828@mail.gmail.com>
Subject: Re: short term branch for project/group keys
Date: Sat, 23 Dec 2006 07:09:07 +1300
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="utf-8";
	reply-type=response
Content-Transfer-Encoding: 7bit

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