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. 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*
