On Sun, Jan 05, 1997 at 05:40:59AM -0500, Graham Fawcett wrote:
> Until a container can abstract persistence to the point where I don't
> care if it's Oracle, ZODB or a set of text-files on the back end of my
> application (never, perhaps?), I suspect that their usefulness is

I'm doubtful that's ever going to be practical, because there are too
many differences to paper over.  RDBMSes and ZODB support
transactions; flat files or a DBM hash don't.  Taking a more
restricted subset seems more feasible -- SQLObject can store objects
in one of several SQL databases, for example.

A lot of attention is paid to generalization -- run this application
with one of ten different back-ends -- but I'm not sure we get that
much benefit from the effort, and it imposes costs.  You need to write
special interfaces that define a common subset of functionality, and
then a bunch of adapter classes that implement the functionality.
Guessed wrong in your method signatures?  Oops; got to update all
those classes now!  Want to make the chosen back-end selectable at
run-time?  Find some configuration machinery to import the right thing
at runtime, but also introduces another source of errors and more code
to dig through when something goes wrong.

Generalization is certainly appropriate if you decide the benefits are
worth the cost, but at times there seems an almost-superstitious
concern with it.

--amk