cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Lazarus <ericllaza...@yahoo.com>
Subject Re: temporal database generation
Date Fri, 25 Aug 2006 16:30:55 GMT
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 <mkienenb@gmail.com> 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&cent;/min.
Mime
  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message