the merge.
What do others think?
Cheers,
Rahul
- Original Message -
From: Jesse McConnell [EMAIL PROTECTED]
To: continuum-dev@maven.apache.org
Sent: Friday, December 22, 2006 8:30 AM
Subject: short term branch for project/group keys
I am thinking about pulling a short term
]
To: continuum-dev@maven.apache.org
Sent: Saturday, January 20, 2007 5:11 AM
Subject: Re: short term branch for project/group keys
sounds good :)
On 1/18/07, Rahul Thakur [EMAIL PROTECTED] wrote:
Hey Jesse,
I am gonna fork a new branch tonight and get started on this change.
Hopefully should
-
From: Jesse McConnell [EMAIL PROTECTED]
To: continuum-dev@maven.apache.org
Sent: Friday, December 22, 2006 8:30 AM
Subject: short term branch for project/group keys
I am thinking about pulling a short term branch of continuum with
rahul and working on getting everything converted to using a string
think?
Cheers,
Rahul
- Original Message -
From: Jesse McConnell [EMAIL PROTECTED]
To: continuum-dev@maven.apache.org
Sent: Friday, December 22, 2006 8:30 AM
Subject: short term branch for project/group keys
I am thinking about pulling a short term branch of continuum with
rahul
-
From: Jesse McConnell [EMAIL PROTECTED]
To: continuum-dev@maven.apache.org
Sent: Friday, December 22, 2006 8:30 AM
Subject: short term branch for project/group keys
I am thinking about pulling a short term branch of continuum with
rahul and working on getting everything converted to using
On 27/12/2006, at 7:10 PM, Rahul Thakur wrote:
Updates to any children hanging off key entities should cascade.
This makes sense if and only if the children are dependent. So, for
build definitions - that's right. Profiles and such are all 'links'
and so will be managed by the normal
Yes, it's fetch groups. The store (pre-groups) took all this into
account, however the lack of central management for some of it caused
it to be pretty error prone. Those problems were related to
Continuum's design, not anything to do with the use of JPOX (and
something that'd be
branch for project/group keys
rahul and I have been talking on skype some working out some of the
details of this key refactor and we see an opportunity to do a few
things that might make life better for continuum.
He is going to mail soon on some things that we are wanting to do in
the store
On 27/12/2006, at 8:28 AM, Jesse McConnell wrote:
Rahul is going to mail on how this can be cleaned up in the store api,
but I question why we want these methods on the Continuum interface at
all?
I think it's there as the application interface - for use from the
webapp and the xmlrpc
On 27/12/2006, at 7:10 PM, Rahul Thakur wrote:
Updates to any children hanging off key entities should cascade.
This makes sense if and only if the children are dependent. So, for
build definitions - that's right. Profiles and such are all 'links'
and so will be managed by the normal
rahul and I have been talking on skype some working out some of the
details of this key refactor and we see an opportunity to do a few
things that might make life better for continuum.
He is going to mail soon on some things that we are wanting to do in
the store and this mail is one something
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
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
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 [EMAIL PROTECTED] wrote:
This all sounds great, but why do they need to be immutable? If they
are essentially used for lookups, and they
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 [EMAIL PROTECTED]
To: continuum-dev@maven.apache.org
Sent: Saturday, December 23, 2006 6:48 AM
Subject: Re: short term branch
On 23/12/2006, at 12:24 AM, Jesse McConnell wrote:
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.
Ok, so a project(Group)? will have:
id : int
key : String
name : String
If we use JPA or some such with caching at the HttpSession-scoped level
for keys (with some fancy dealing, I admit) we can have each person's
view independent on a per-session basis. That is, the key will be
translated into an id _in that person's context_, and the real id's are
used to fetch.
Whoa. Repeat the mantra - convention over configuration :)
One of the great strengths of Continuum is that it takes its defaults
from Maven. Sure, they can be changeable, but they *must* be the
default. That's not a mess.
ok, that idea is actually in my old thread on this topic..
my intention
[snip]
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.
Ok, so a project(Group)? will have:
id : int
key : String
name : String
...
Where key is used as a reference, id is
On 23/12/2006, at 1:34 PM, Rahul Thakur wrote:
That was my point in my last email. I understand why we need that
old key table but this would be something that will just get
bloated over time. There could be a 'housekeeper' process that can
clean up old keys after a certain time has
Sounds great to me. But I'm confused. Are the api's passing around
keys as in database keys (id), or so-called business keys, i.e. the
project group's text id and the project's text id? I presume the
latter, given the earlier discussions.
Christian.
Jesse McConnell wrote:
I am thinking about
The web pages use a combination of id's which are currently jpox id's
and in some places the actual freeform name string is being passed
around on the URL in order to influence program logic and security
decisions..
all of that is what I want to unite behind stronger typed string keys.
jesse
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.
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
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
24 matches
Mail list logo
