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