En/na [EMAIL PROTECTED] ha escrit:

Martijn Faassen wrote:
Missing powerful query concepts

Certain powerful query concepts like joins, available in a relational
setting, are missing. I've already run into a scenario where I wanted to
someting like this: given a bunch of version objects with field 'id',
where multiple objects can have the same 'id' to indicate they're
versions of the same object, I want all objects where field
'workflow_state' is 'PUBLISHED' unless there is another object with the
same id that have workflow_state 'NEW', in which case I want that one'.

I think joins would be a way to solve it, though I haven't figured out
the details, nor how to implement them efficiently on top of the
catalog. This kind of thing is where a relational database makes life a
lot simpler.

I used to have the same complaints in Zope 2, but so far I've been happy
with Dieter's AdvancedQuery product.  See
It might be worth a look while thinking about what to implement for zope 3.
A very interesing discussion. I'm just and advanced Zope 2 user, and a Zope 3 beginner, but those questions are over my head since I start to develop using ZODB, so I will put here my opinions.

The use of ZODB and ZCatalogs has a lot of advantatges, that's obvious, but also has some limitations. We also use AdvancedQuery to solve some of them, but there are another not solved ones:

1) Join's. There isn't an standard way to make joins, and also to make sorts and filters over joined data. I know that with enought python knowledge this can be done manually, but that's hard (at least much more hard than using SQL). Moreover, programmers writing business application reports are the ones with less python experience and, believe me, some joins can be writted in a very unefficient way :-)

2) Relational Integrity. I like to make a data definition and rely on it, so if I define that an invoice has a restricted foreign key with a customer, the customer will not be deleted while the invoice exists. Despide this behaviours could (and should) be implemented in the application logic, sometimes there are bugs in the application and data inconsistencies are generated. Working with RDBM's you could rely on your data definition, so data inconsistencies never will be done.

3) Huge amounts of data. When working with applications writing a lot of data or making queries (in special join's) over huge amount of data, the performance of a ZODB database is poor in front of some RDBM's (I'm talking about Zope 2.7, I haven't this experience with Z3 yet).

Despide of this, I think the advantatges of use ZODB are more than the limitations, so we continue using it. I think a good approach could be a transparent O/R mapping plus a way to use SQL over the RDBM's and get objects back. That way, a pure ZODB application can work with FileStorage or with a RDBM's storage, and applications requiring it will be able to take advantage of SQL.

I just want to express an opinion from a user that simply uses ZODB and ZCatalogs, and that has been using RDBM's for a long time before.


Santi Camps

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to