At 01:49 PM 10/3/00 -0700, John Eikenberry wrote:
First, some context... I'm working on a new data storage system for a related set of (primarily) Zope sites. The data will be kept in ZODB and mirrored out to a RDB (MySQL) to provide read-only access to some non-zope stuff. One other thing to note, all of this will be done via python code (no zclasses).
Now say that I want to keep data about a company. I have a specialist, rack and dataskin already created. I currently can store data on the skin via AttributeProviders, but this was mainly done to get something working to mess around with.
What I think I want is several SheetProviders. Two for each block of data (a block basically reflect the breakdown of tables in the MySQL DB). Why 2 for each block, one for the ZODB store and one for mirroring the data out to the RDB. So, the breakdown for the company would look like this:
Company Rack - Company Information (name, url, etc). . SheetProvider (ZODB) - read/write . SheetProvider (SQL) - write only - Address Information (city, state, zip, etc) . SheetProvider (ZODB) - read/write . SheetProvider (SQL) - write only
Does this sound reasonable? I thought about writing a mix-in class to add the SQL stuff to the SheetProvider, eliminating the need for 2 entries for each block of data. But I liked the idea of each being its own plugin, seemed cleaner.
If I can offer a suggestion... It sounds to me like you don't need SheetProviders at all, if you effectively define the property sheets as part of your class, and make the attributes direct attributes on the DataSkin. You then need only set up a single trigger that checks whether any of the attributes you want to mirror have changed, and then fires that off to the SQL db. It would actually be a bit easier to set up if you were using a ZClass, since you could create the property sheets there by just adding "DataSkin Property Sheet" objects to the ZClass. But the basic principle would still apply.