Hey Eric, By the end of the month, I will have audit logging like you've described working. Probably Monday or Tuesday. If it involves code changes to Cayenne, it'll probably take at least another week to get them committed.
Some of the details of what we've discussed before are here: http://objectstyle.org/jira/secure/ViewIssue.jspa?key=CAY-414 I have done this before with varying success under Cayenne 1.1 (no join tables) and earlier versions of Cayenne 1.2 (FlattenedRelationship access with a customized version of Cayenne), but I'm only now getting back to it using standard features in Cayenne 1.2. Other threads you might find interesting are No access to getObjectStore().getFlattenedInserts() / getFlattenedDeletes() Dec 20th, 2005 Setting a relationship to a generic DataObject in order to log the primary key value Dec 20th, 2005 On 8/25/06, Eric Lazarus <[EMAIL PROTECTED]> wrote:
Tomi Exciting that you started this thread! Very much on my mind. In my application, it would be super cool to log every change that any user made to any entity so that no state of any "deal" in the application would ever be lost. If I could do this without making my object model ugly, that would be really cool. I would want to be able to show a log of changes to my users on the one hand and also to return a particular deal (composite object) to an earlier state and also make that state the current state (i.e., "back out" changes since a particular time in the past.) If I were using a normal relational mode, much of this would be pretty easy to do but with OR mapping, it does seem to be a challenge. In the conventional relational world, I would add a "effectiveStartTime" and "effectiveEndTime" to every relevant table. It would make all my queries more complex but it would be easy to UNDERSTAND how to accomplish this. I have no idea what my realistic options would be for building a "non-destructive" database in Cayenne where nothing is every overwritten and it is easy to get to and use that "out of date" data as well as the "up to date" data. What are the design alternatives for doing this sort of thing? Why would one pick one over another? Thanks, Eric Mike Kienenberger <[EMAIL PROTECTED]> wrote: In my opinion, (and maybe I'm short-sighted), this is really an application-level thing. If I were going to implement it to be universal, I'd subclass DataContext (easy to do with a DataContextFactory), have a timestamp property on it, and automatically update what happens when a query is performed (append date between expressions to each table -- this is probably the hard part) and committed (automatically update the date fields). On 8/25/06, Tomi NA wrote: > I've been tasked with designing a system, including it's database to > capture data which changes through time but shouldn't overwrite > existing values. I've also ran into other people describing these > kinds of databases in their work, referring to them as "temporal > databases". > Here's why I'm writing to the cayenne list about it. I've been > thinking...say you started with a regular database model (a cayenne > model or an existing db model) like you would on any project. The > modeler could conceivably generate the whole thing: a pair of > "valid_from" - "valid_to" fields in every table, code which would > transform an update command into a relevant update/insert command pair > and finally, code which would allow transparent access to the most > current information stored in the database. > The generated API would be almost identical to the one cayenne > generates now for a "plain" database, the only exception being the > possibility to define a timestamp (maybe at the context level) which > would allow you to do the same (SELECT) queries, but effectively > moving back in time to the desired moment. > > Concievably, you could do something like this: > DataContext dc = ...; > dc.setPointInTime(beginningOfTheYear); > // prints out the number of employees on 2006-01-01 > System.out.println(dc.performQuery(new SelectQuery(Employee.class)).size()); > dc.setPointInTime(now); > // prints out the number of employees on 2006-08-25 > System.out.println(dc.performQuery(new SelectQuery(Employee.class)).size()); > > Obviously, a database like this would grow possibly very fast so it > might not be a suitable design where space is a major concern, but I > can think of a lot of applications where this would be a fantastic > thing to have out of the box. > > I'd appreciate anyone with an opinion on this to comment. > > TIA, > t.n.a. > --------------------------------- Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1ยข/min.
