RE: [Zope] ZODB vs SQL, ZTables
-----Original Message----- From: Jordan B. Baker [mailto:jbb@spyderlab.com] Sent: Monday, June 07, 1999 12:20 PM To: zope@zope.org Subject: [Zope] ZODB vs SQL, ZTables
hi zopesters:
I am designing an application where I'd like use the ZODB as the primary storage and the objects being instances of ZClasses.
I'd like to navigate through them using a hierarchal category system.
Now, I assume that once I have this I can also provide other ways to traverse the data by building indexes. I realize this isn't quite documented yet and its not totally importart atm because the dataset size is small enough, but I'd like allow this app. to scale.
I'm not sure if building indexes is the only way to get another 'view' of the data stored in the ZODB. I could write an exthernal method to query using the 'slow' objectValues() method, I suppose.
The questions I have are:
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.
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.
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.
Has anyone tackled any of these issues? Was it worth it?
We are tackling it internally, whether it was worth it or not is yet to be seen. ;) (give us lots of money, and it's worth it) 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. -Michel
Thanks guys,
------- 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 )
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. 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
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"
participants (3)
-
Howard Clinton Shaw III -
Jordan B. Baker -
Michel Pelletier