Re: [Zope-dev] Re: The remaining spanner in the works :-)

2002-08-02 Thread Gary Poster

I agree with Chris: *wow*!

[re the original explanation]
...
 I'm sure I left a few things out, so ask questions about the unclear
 parts.  

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.

 It's probably more info than you were expecting. ;-)

Yes, and much appreciated.

[re the solution to Chris's spanner]
...
 Finally, here's a theoretical solution that I think would be ideal for a 
 lot of people: if we could just ask the RDBMS for its current 
 transaction ID, Zope could keep track of the last transaction ID it knew 
 about, and clear the caches when another process made a change.  This 
 solution may yield the highest performance for Zope-centric 
 applications.  It would also remove the need for my MD5 hack. ;-)

This does sound good.

Zope3 will rule the world!  ;-)

Gary


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Re: The remaining spanner in the works :-)

2002-08-02 Thread Shane Hathaway

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
parts.  
 
 
 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.

Shane


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )