On Mon, 11 Feb 2002 00:15:57 -0800, Chris Harris <[EMAIL PROTECTED]> wrote:
>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? > [clip] Versioning is a big subject, and there are a number of approaches you might take. ObjectStore (pure-OODB) had a versioning feature built-in a few years ago, but they ripped it out because it was impossible to make it meet everyone's needs. I think this is why you don't see versioning in EJB yet. One pattern I've seen is to use a dynamic attribute list on the beans. This is a list of name-value pair objects that gets attached to each bean. Each bean can have an arbitrary set of attributes then. Attrs are looked up by name; if the attr doesn't exist on the object, you can build in default behavior and handle exceptions gracefully. The whole mechanism can be encapsulated, reused across bean types, taught to load & store, etc. This pattern is not restricted to versioning, but it helps a great deal in versioned objects. The beans can have versions, with different versions having different attr sets. Your business logic does not have to know which versions have which attrs, you simply go for the attr value, and it either defaults or throws exceptions if it's not there. The performance penalty is not too high for the name lookup if the attr list is small. The version does not have to be in the PK. Since you're not messing with the PK, your relationships are unaffected. This allows your beans to have the same extensibility and backward-compatibility characteristics as XML. This pattern does not help if your beans need different methods between versions. This construct persists like a dream in an OODB, and greatly simplifies the problem of schema evolution of the database (a version-related problem.) It would also store in an RDBMS, probably less efficiently. Tom Groot (with Object Design in a past life) =========================================================================== 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".
