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 Sat, 26 Aug 2006 17:04:34 GMT
I guess I was thinking about it done in Tomi's way but if this way can ensure that no data
is ever lost, that is pretty powerful.

What are the advantages of doing it Tomi's way?

   He can do efficient queries to see what the state of the database was at any time in the
past? Is that right? 

   He could efficiently materialize objects as they existed at any time in the past. 

Anything else?

The general idea that a "fact" can be "tagged" is a general and powerful concept that OR tools
perhaps should support in some way. What might one want to "tag" a "fact" with? It isn't just
"time" that it makes sense to tag things with. 


   Why I believe it.
   Who expressed it.
   Who believes it / does not believe it. 

   What process did we use to learn/discover the fact.
   What process did we use to MAKE it true.
   Level of certainty. 

   Importance / relevance. 

   Implications of the fact. 

   When it came to be.
   When it stopped being true.
   Why it is true. 

   From what "point of view" is it true (i.e., the prosecution vs. the defense in a legal
battle)


(I guess this is somewhat related to the ideas of higher order logic, where we quantify over
predicates? Hmmm...)

Objects are not as good as relations at looking at the world as a set of facts, are they?


It would be so cool for objects to be able to support this and still retain the clean way
we model other things so nicely using objects. 

I dont currently have lots of ideas about how one would make this generally practical within
the context of OO programming.

I did consult to a consumer goods company where the tree of geographical regains was represented
in the relational database with start and end dates so that areas could come into existence,
be re-classified into different sub regions. I guess it had to do with who managed  what sales
staff member at what period of time and who got what discounts. 

Sorry if this is an example of generalizing to the point of impracticality. I have no actual
near-term requirement for this sort of thing.

E
 

Mike Kienenberger <mkienenb@gmail.com> wrote: The main difference is that Tomi needs
to have automatic criteria
applied to every query he makes.   Ie, a "WHERE time between
effectivestart and effectiveend" for every select, insert, and update.

What I need, and what Eric sounds like he needs, is for an AUDIT_LOG
record to be created for every insert, update, and delete.   Actually
one for every field changed in an insert or update.

For example, here's what the fields of an audit record look like for
me (xml definition).



    
position="5" primaryKey="true" type="INTEGER" />
    
nullable="true" position="11" primaryKey="false" size="32"
type="VARCHAR" />
    
nullable="true" position="13" primaryKey="false" size="32"
type="VARCHAR" />
    
nullable="true" position="1" primaryKey="false" size="32"
type="VARCHAR" />
    
nullable="true" position="7" primaryKey="false" size="1"
type="VARCHAR" />
    
nullable="true" position="9" primaryKey="false" size="2000"
type="VARCHAR" />
    
nullable="true" position="8" primaryKey="false" size="2000"
type="VARCHAR" />
    
nullable="true" position="4" primaryKey="false" type="INTEGER" />
    
nullable="true" position="3" primaryKey="false" size="200"
type="VARCHAR" />
    
nullable="true" position="6" primaryKey="false" size="6"
type="TIMESTAMP" />
    
nullable="true" position="12" primaryKey="false" type="INTEGER" />
    
nullable="true" position="2" primaryKey="false" type="INTEGER" />
    
nullable="true" position="10" primaryKey="false" type="INTEGER" />


ID is meaningless primary key
SCHEMA_NAME.TBL_NAME.COL_NAME describes path to data changed.
MOD_TYPE is insert, delete, or update (I,D,U)
OLD_VALUE and NEW_VALUE are the state changes.
FOREIGN_KEY and FKEY_CONDITION are references to the record that was
changed (FK_C is for compound keys, FK is for a single integer key).
MOD_TIME is when the record was changed.
SYSTEM_ID/EFFECTIVE_USER_ID/REAL_USER_ID describes where the data was
changed. (application and user).


On 8/25/06, Eric Lazarus  wrote:
> Tomi
>
> Please help me/us to understand what you need and how it differs from what I am talking
about (or what additional functionality you need.)
>
> Thanks
>
> Eric
>
> Tomi NA  wrote: On 8/25/06, Mike Kienenberger  wrote:
> > 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.
>
> I'm looking forward to seeing how it'll work. From the JIRA issue you
> linked to, it didn't seem like the functionality I described, but if
> you say it's what Eric described he needed, then it's (for the most
> part) the functionality I need, as well.
>
>
>
> ---------------------------------
> Do you Yahoo!?
>  Everyone is raving about the  all-new Yahoo! Mail.
>


 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
Mime
  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message