Jesse and myself had a chat yesterday morning about the key-refactoring
branch that we spun before Christmas last year, and we reckon that it
might be an idea to get 1.1-alpha rolling and meantime gather more
thoughts around Groupings (introduce versions/tags). We think having
String-based keys
I am loathe to let a branch lay around for a long time with minimal
work being done actively on it and we learned what we wanted to from
it in the short time we worked with it I think.
my take-away was that the change the string based keys will be a good
change but its large enough that it
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
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.
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
13 matches
Mail list logo
