[TransWarp] policies for handline changing Records
Phillip J. Eby
pje at telecommunity.com
Sun Mar 10 16:50:11 EST 2002
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
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
>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. :)
More information about the PEAK