On 22 Dec 06, at 10:33 PM 22 Dec 06, Christian Edward Gruber wrote:
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. So a key change will only affect them when their keys
refresh. Now we need a strategy for refresh, but hey... one
problem at
a time. :)
Yah, you can't think of any specific persistence store here as the
store api should work with any persistence mechanism.
Jason.
Not the best idea I've had, but more to point out that there are some
solutions to this that can be fairly simple in practice.
Christian
Rahul Thakur wrote:
[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 used as a datastore/model
identity, and name is used as a display. Sounds good.
We could then have a table of "old names":
id : int
oldKey : String
These could be used so that failed lookup on a key could then
look in
the old key's to find out what the new one is (like when you move an
issue in JIRA). I'm not sure this is needed initially - only if we
support picking up renames to the project itself.
[/snip]
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 expired. I don't see a reason why we
need to keep the old stuff for long.
Cheers,
Rahul
--
*christian** gruber + process coach and architect*
*Israfil Consulting Services Corporation*
*email** [EMAIL PROTECTED] + bus 905.640.1119 + mob 416.998.6023*
