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 
general enough!

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 - )

Reply via email to