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 Zope3firstname.lastname@example.org http://mail.zope.org/mailman/listinfo/zope3-users