[Zope3-Users] zql

[Chris McDonough]

Just curious: instead of writing a query language implementation, why  
not use a relational database to store the data that is likely to  
need to be queried in an arbitrary way?  You do still get most of the  
good stuff in Zope if you do this and it's a lot less work.

On Apr 23, 2006, at 3:25 PM, Pete Taylor wrote:

> 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 etc...how 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
> "Jimmy".
>
> 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
> applications.
>
> 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?
>
> Pete
>
> --
> "All guilt is relative, loyalty counts, and never let your conscience
> be your guide."
>   - Lucas Buck, American Gothic
> _______________________________________________
> Zope3-users mailing list
> Zope3-users at zope.org
> http://mail.zope.org/mailman/listinfo/zope3-users
>