continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <ja...@maven.org>
Subject Re: short term branch for project/group keys
Date Sat, 23 Dec 2006 14:40:05 GMT

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** cgruber@israfil.net + bus 905.640.1119 + mob 416.998.6023*
>


Mime
View raw message