I too have this requirement and would be interested in any answers. From the silence on the list it sounds like not many people need to version their entitities.
Issues I have are similar to yours, but with one extra: some of our business entities are in fact object graphs involving several fine-grained entitites and relationships between them (no CMR, yet - waiting for JBoss 3!) with a session facade in front. Maintaining these entities, and histories of them, gets very complicated since you now have to maintain the version numbers of all the entities within the relationship (e.g. version 12 of entity A links to version 6 of entity B, version 13 of entity A links to version 27 of entity B etc.) Right now I don't have an answer for that. The obvious way would be to extend the primary keys of the entities to include version numbers but I'd rather not go down that road since at the moment my PKs are all nice efficient 'longs'. Some kind of Decorator to wrap the entitites and cope with versioned relationships might be an answer but then any hope of using CMR would go out fo the window (not necessarily a problem since we already have named, weighted arbitrary relationships modelled in our database schema). The main issue if you don't have to deal with versioned relations is that of storage. You can either go with a compound PK field (so your new PK = old PK + version number) at the expense of being able to treat PKs as atomic, or use history tables (copies of your main tables but holding all the old versions) and write the extra code to handle them. Neither solution is particularly elegant. History tables could be done at the database level with triggers to keep the application code down, depending on your requirements. Our project is mainly concerned with audit trails rather than being able to 'rollback' versions of objects, so it's not certain that lots of application code is needed for these versioned objects. Presumably a pure object db would handle some of these issues easily? c --- Dmitri Colebatch <[EMAIL PROTECTED]> wrote: > hey all, > > writing to see if anyone has done work with versioning on > top of entity beans. I've been given a requirement to > have a particular > entity versioned, _and_ retain previous versions (so a > simple version field, a la soft locking, wont suffice). > > The issues I've identified are: > a) ensuring that old versions are not changed, but > instead new ones created > b) maintaining a list of versions > c) allowing a version to be modified whilst it is being > created, ie - for a user to create an entity using a web > interface (with > multiple round trips), without creating a new version for > each round trip. > > ok, for (a) I see that I should ensure all access goes > through a SLSB, and not to the EB itself. Pretty happy > with that. > > for (b) I had been thinking of keeping a reference to the > previous version, so I have a chain of entities. this > would make creating > the entire list of versions difficult, but would allow > some level of access to previous versions. > > for (c) the obvious solution is a value-object, and > create it all at once. but I've been given the > requirement that work must not > be lost when a session times out. Which _could_ involve > using a stateful session bean, but I'm not sure. I'm > thinking I'll try and > bump the requirement. > > if anyone's already been down this road, I'd welcome any > opinions/input. > > one last point - it may of course turn out that these > requirements mean ejb just isn't right. My #1 > requirement is that this is > done asap (how unusual :), but if anyone wants to point > me elsewhere as well, that too would be good. > > cheers > dim > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and > include in the body > of the message "signoff EJB-INTEREST". For general help, > send email to > [EMAIL PROTECTED] and include in the body of the > message "help". > __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
