Hi Nathan, Thanks for your thoughts.
On 9 Oct 2007 at 11:25, Nathan Anderson wrote: > We have an app that uses the Hibernate version attribute to make a "archive > table" like you describe. > > Some things to think about before you get too far... The foreign key > constraint means you will not be able to > delete an object without deleting it's archive [which is bad ;)]. That's a good point. I may have to skip the DB-based FK constraint and code this kind of thing in Java, which would be extra overhead. I'll take a closer look at some of the Hibernate join options in case there's something hidden in the detail there that could help. The other option could be a "Deleted" flag in the tables. > We used the composite key without any real problem [object key + version]. > We also added two additional fields to > the archive record "modified timestamp" and "modified by". > > It works very well for our needs but the one thing that has bugged me is that > it is sometimes difficult to see what > has changed from one version to the next. But that is more of an UI problem > than a data problem. FYI, this is in > an AppFuse 1.x app but the same basic idea should apply to either major > version of AppFuse. I agree that the AppFuse version should have no bearing on this as most of it happens at the DB level anyway. Did your tables have large numbers of records? I'm concerned that in a table with many records, and particularly many changes to records, a simple process like listing the (current version of the) rows in the table could be quite resource intensive, especially given that it would involve a "max(version)" for each row. Cheers, Rob Hills Waikiki, Western Australia Mobile +61 (412) 904-357 Fax: +61 (8) 9529-2137 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
