t; <[EMAIL PROTECTED]>
To:
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 sh
t;> are now converted to 'long'. Some other bits like breaking up the
>> existing Project and ProjectGroup interfaces can be continued on the
>> trunk itself after the merge.
>>
>> What do others think?
>>
>> Cheers,
>> Rahul
>>
Rahul
- Original Message -
From: "Jesse McConnell" <[EMAIL PROTECTED]>
To:
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 everyth
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 for
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 inter
ts, groups.
Operations on Schedules, profiles etc)
The names above are just indicative, we can change them later :-)
Thoughts?
Cheers,
Rahul
- Original Message -
From: "Jesse McConnell" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, December 27, 2006 10:28 AM
Subject: Re: short ter
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 to
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 expir
[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 use
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
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
11 matches
Mail list logo
