Re: Alternative Storages: (was RelationalStorage (was LocalFS))
Just one point. The concept of abstraction to enable any SQL compatible RDBMS makes perfect sense, to a rigorously OO way of thinking. Ironically, strict adherance can sometimes lead down a path where a truly marvelous option is dismissed, simply because it is unique. The objects to be stored are, after all, objects, not data fields. The shortcomings of FileStorage are limitations related to heavy writes, and non-atomic undo. Other aspects have proven very appropriate for the task of enabling persistence in objects. The inherent features of PostgreSQL to allow user defined, inheritable datatypes, suggests remarkable synergies with the intention of the proposed DB Storage, if not with every stated goal. It seems a shame to ignore this possibility just because Oracle / MySQL have so much mindshare. When such a tool exists that excels at storing objects, in a tabular sort of way, should it's special talents be disregarded just to avoid overdependence on an incomparably suitable solution? In the worst case, perhaps a PostgreSQL implementation of a Rack could be expected to directly handle aspects of Object Persistence that must be supplemented with Property Sheets, etc. in alternate implementations. Just in case a Zope newbie is reading this, and hasn't heard of PostgreSQL before, it is also Open Source. http://www.postgresql.org Later, Jerry S.
Jerry wrote:
Just one point. The concept of abstraction to enable any SQL compatible RDBMS makes perfect sense, to a rigorously OO way of thinking. Ironically, strict adherance can sometimes lead down a path where a truly marvelous option is dismissed, simply because it is unique.
[snip]
The inherent features of PostgreSQL to allow user defined, inheritable datatypes, suggests remarkable synergies with the intention of the proposed DB Storage, if not with every stated goal. It seems a shame to ignore this possibility just because Oracle / MySQL have so much mindshare. When such a tool exists that excels at storing objects, in a tabular sort of way, should it's special talents be disregarded just to avoid overdependence on an incomparably suitable solution?
It hasn't much to do with mindshare... MySQL and Oracle (and actually InterBase as well) are frontrunning candidates for development of RelationalStorage because they already have Python DB-API2 compliant adapters written for them. Postgres can certainly handle it (AFAICT it's ideal), but I don't much feel like writing to a non-DBAPI compliant in the first cut as it limits the platform to *only* posgres initially, and I don't want to wrap the existing postgres da in a DB-API2 wrapper or anything (it's just no fun). Hopefully, once there is some code to poke at, people will modify it to make it work against their database of choice. -- Chris McDonough Digital Creations Publishers of Zope - http://www.zope.org
At 10:25 PM 5/3/00 +0000, Jerry wrote:
In the worst case, perhaps a PostgreSQL implementation of a Rack could be expected to directly handle aspects of Object Persistence that must be supplemented with Property Sheets, etc. in alternate implementations.
Once there's an SQLRack done (probably this summer, unless somebody else takes up the gauntlet sooner), it would be straightforward to add additional functionality. All the ZPatterns tools are based on a plugin architecture, and in the case of Rack, there are tabs where you can add "Attribute Providers" and "Sheet Providers". To do what you describe, one would write an AttributeProvider class that worked with whatever PostgreSQL capabilities were desired. The user of a Rack would then simply select your AttributeProvider from the appropriate tab's "Add" list, and then configure it. Part of your class's behavior would be to inform the containing rack what attributes it handles read requests for, and which it handles write requests for. Note, by the way, that an AttributeProvider or SheetProvider does not have to store its data in the same place where the "base object" is stored. One could provide PostgreSQL data for a persistent object, or persistent data for a PostgreSQL object, or merge two SQL databases' data together with an LDAP entry. The Rack doesn't care, it just passes on the RackMountables' requests for data to the registered providers for that data.
participants (3)
-
Chris McDonough -
Jerry -
Phillip J. Eby