Gary Poster wrote:
> I agree with Chris: *wow*!
> [re the original explanation]
>>I'm sure I left a few things out, so ask questions about the unclear
> Everything was wonderfully clear, except that the actual mechanism to
> convert the nested tuples flexibly to RDBMS record sequences escaped me
> a bit. This probably gets in the realm of "look at the code" which is
> what, in fact, I will hope to do.
I created another set of components called "record storages". Their job
is to load and store record sequences in a schema that matches that of a
serializer. In the current AdaptableStorage code, most of them are
still called a "table", the old name for "record storage", but when I
started serializing to the filesystem I realized that "table" wasn't
Most record storages store data in some kind of database, but other
record storages act as a proxy for other record storages, converting
data in one schema to another. This theoretically enables application
developers and database administrators to work independently, bringing
their work together through proxy record storages.
Record storages are similar to SQLMethods, with the difference that
record storages provide a way to both read and write a set of records.
Conventionally, SQLMethods either read or write data, but not both
(Though it's possible to write a SQLMethod that can read or write
depending on the argument signature, that's not what they were designed
to do. Instead, a record storage might consist of two or more SQL methods.)
Some record storages might actually perform complex database queries
that are not sensible to store. In that case, you can just raise a
ReadOnlyError on an attempt to write.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -