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
|