hmm again ;)

> In reality you don't want to search inside a RDBMS for unindexed data
> for performance reasons. This is even more true for Zope since you have to
> read all data of the ZODB..this will be totally inefficient especially
> for large installations.

you're absolutely right that you don't want to search in an rdbms for
unindexed data.  anyone who's had a dba forget to bring the indexes
across when migrating a database can attest to that :)  still, the
issue, to my mind, is that you *can* query against that data, it's
still accessible using the same tools.

> Zope object can be very complex: attributes can be
> basic Python types, Zope BTrees, hierarchial data will you define
> a query language that covers all use cases? In Zope 2 we have something
> like AdvancedQuery to specify almost generic queries for the ZCatalog..I
> think hurry was inspired by AdvancedQuery. Of course you can define
> something that implements a particular subset of all possibile types and
> query types . But when it comes to the point where the functionality is too
> limited you end up writing you queries based on the functionality the core
> engine gives you.
> -aj

i see what you mean, and again don't disagree.  but i wouldn't be
opposed even to making some kind of registerable attribute at class
construction that says "user_space" vs "application_space" or
"utility_space" type object.  i'm not concerned about being able to
query the zodb for utility-style class content, nor really any content
that is in the "application" space (content objects there only to
present a view for some specific action, etc).  but all content that
is there for users to actually interact with...  say an application
administrator that wants to look up every place in the site where some
object "CustomerData" is associated to some "Customer" object named

i suppose it comes down to the idea that i don't want to be the
gatekeeper for information in the zodb, nor do my developers.  if i
can't teach a reasonably intelligent user how to access their own data
with a tool that looks like what they've seen before (or build them a
wxPython frontend to the same ;) ), i'll have real trouble getting
buy-in to use zope3 in a larger context than small-return

i like the conversation though, and from your contentions, it's
obvious i don't know all the complexities.  still, i'd like to keep at
it, at least in discussion, before throwing it out.  i love zope3, but
if developers are the only ones who can get at data, it won't matter
how much _i_ like it, y'know?


"All guilt is relative, loyalty counts, and never let your conscience
be your guide."
  - Lucas Buck, American Gothic
Zope3-users mailing list

Reply via email to