[Zope] ZODB vs SQL, ZTables

[Howard Clinton Shaw III]

On Mon, 07 Jun 1999, Jordan B. Baker wrote:
> On Mon, 7 Jun 1999, Michel Pelletier wrote:
> 
> > > 1) Would I be re-inventing the wheel here?  Can ZTables instantiate
> > > ZClasses?  The reason I like the ZClasses is because I'd like 
> > > to write my
> > > business logic in Python.  I suppose I could do this with External
> > > methods.
> > 
> > ZTables return an result 'object' called a 'brain'.  This object is
> > instanciated on the fly when you make queries.  If you define your own
> > type of brain, then you can have your own types of objects.  I don't see
> > any reason why this object couldn't be a ZClass, but currently there is
> > no mechanism to hook the two together through the ZClass, there would
> > have to be some python involved.
> 
> This is pretty intriguing.  I need to consider the cost/benefits.
> 
> One thing I don't like about this is that (I assume) you can't change the
> data in the ZTable simply by assigning attributes as you could if each
> piece of data was stored as objects.
> 

Maybe not directly, but you could write a python object/Product which would
connect to a given ZTable and provide access like
ZT[column,value].othercolumn=value by defining the double underscore methods.

Its not hard to wrap flat data to look like objects in Python; just look at Tkinter!

> Either way it would be fairly easy to write getter/setter methods that
> would use a ZTables API to update the records.  I assume this would work
> anyway.
> 
> > > 2) I realize the indexing system isn't well documented at > this
> > point, but > if you can figure out the system is it usable? :) >
> > 
> > It's very usable.  I'm working on some documentation for it right now,
> > but it might be lower level than you think.  What you might want to wait
> > for is the Catalog, whose purpose is to do exactly what you want,
> > catalog and index Zope objects.
> 
> Well, I'd certainly be willing to provide feedback on the documentation as
> this would give me an idea of how it works at a lower level.  And it means
> I could start protyping some of my ideas today instead of waiting for the
> internal QA of the Catalog to move along.
> 
> > > I'm just struggling a bit with the concepts of going 
> > > completely OO instead
> > > of storing my data in a SQL database.
> > 
> > There are benefits to using SQL, and there are benefits to using
> > objects.  You have to weigh these things when elaborating your design.
> > if you think your system is very object oriented, or very relational, or
> > a hybrid of the two.
> 
> Yes, thanks for pointing that out.  I do find that certain data structures
> are a pain to implement in SQL.  Ie, when you want an ordered list of
> items.
> 
> Certain factors are pointing towards using the object database here.  
> Main one is the portability and flexibility.  Using ZClasses is nicer
> still because I'd like to provide a seperate property sheet for users to
> customize each object if they like.
> 
> > The catalog is designed to do almost exactly what your looking for.  
> > It's unclear at the moment what exactly will get open sourced as a the
> > 'catalog' since the catalog consists of several layers of components
> > at the moment. Chances are there will be no managment interface (maybe
> > a minimal one), just a DTML API which you can use to search or
> > manipulate the catalog.
> 
> Hmm, probably that's about all I'd need anyway.
> 
> If there is any alpha testing going with it I'd be willing to run it
> through its paces.  Otherwise roughly when do you think Catalog will be
> available in some form?
> 
> > -Michel
> 
> Thanks for the great info. I'll chew on this a bit. :)
> 
> -------
> Jordan B. Baker -- jbb@spyderlab.com
> weaving the web @ http://www.spyderlab.com
> 
> 
> 
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://www.zope.org/mailman/listinfo/zope
> 
> (For developer-specific issues, use the companion list,
> zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )
--
Howard Clinton Shaw III - Grum
St. Thomas High School
#include "disclaimer.h"