Initiator: Chris McDonough (email@example.com)
The following high-level goals are served by implementing a Zope Storage on top of a relational database:
- Have a little fun :-)
- Implement a reliable, feature-complete Zope storage that uses a relational database for persistence.
- Provide "large ZODB" support: some if not most relational databases allow you to store fairly large amounts of data without undue trouble. Contrast this with single-file-based storage that has on some platforms an upper limit of 2GB. The recently-added MountedDatabases feature also allows this.
Possible Other Goals
- Grant a level of comfort to customers/users who "just feel better" when things go into a relational DB instead of a filesystem (this is probably more of a "perception" issue than anything).
- Take advantage of high-availability features of common RDBMS systems. This is possibly of questionable value, as the SPOF still remains the storage server, but it sure sounds good. Not necessarily :) See next point.
- Possibly quota support
- (moved additional contributed points to RelationalStorageDiscussion)
RelationalStorage will not be tied to a particular RDBMS. RelationalStorage implementations are happening against Interbase and MySQL? currently in parallel, but perhaps an interface should be abstracted out of the implementations, and eventually a base RelationalStorage class should be subclassed by RDBMS-specific code.
A RelationalStorage class should make use of the services provided by the existing BaseStorage class, which provides thread-locking facilities and other niceties. The BaseStorage class will also be frequently updated to implement the current Storage interface, and will provide inherited methods and attributes defined by this interface as time goes on.