[TransWarp] policies for handline changing Records

[Phillip J. Eby]

At 09:33 PM 3/10/02 +0000, Steve Alexander wrote:

>Philliip wrote in the CVS commit logs:
> >
> > 99% of the time, the policy for whether the record should be queued
> > vs. updating immediately will be determined in the Record, since it
> > ordinarily will be uniform across record types within the same record
> > manager.  In the other 1%, you can always delegate outward from the
> > Record._changedField method.
>
>Can you expand on this please?
>
>I'm particularly interested in what you mean by "queued vs updating 
>immediately", and how you see this being related to different types of record.

In ZPatterns, SQL/LDAP writes are held until (sub)transaction commit, in 
order to avoid make writing to databases more efficient.  This sometimes 
leads to having to do subtransaction commits to fix the fact that your SQL 
data isn't up-to-date during the transaction.

TransWarp, however, uses a simpler update-queuing approach.  A 'Database' 
maintains a queue of dirty records at all times, and at any time can be 
asked to flush them, without any transaction semantics being 
involved.  (The assumption is that whatever database you're writing to is 
going to have transaction support of its own.)  When you implement a query 
method on a RecordType, you can ask the database to flush the update queue 
first, ensuring that the data you're querying is up-to-date.  Of course, if 
you don't manually flush the update queue, it's flushed at transaction 
commit time.

In an earlier design phase, I thought that certain kinds of records might 
need or want write-through semantics, but as things have gotten more 
concrete, I can't actually think of any, so I threw out the default 
delegation to the RecordType, and thus made _changedField() a method of 
Record itself.


>This looks as if it follows a similar pattern to some things I've been 
>thinking about with respect to Zope3 ObjectHubs and indexing.

You tell me.  :)