continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Edward Gruber <>
Subject Re: short term branch for project/group keys
Date Sat, 23 Dec 2006 04:33:44 GMT
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. :)

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.


Rahul Thakur wrote:
> [snip]
>>> the and 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** + bus 905.640.1119 + mob 416.998.6023*

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message