[Zope3-Users] zql

[Pete Taylor]

true enough, which is what we've generally speaking done in the past. 
i guess it's just a question of duplication...  to get at an object in
the zodb, i need to make it persistent.  so i'm holding my data there.
 but then i want to get at it in an rdb, so i have to make sure it
gets there too.  but say i delete, update, modify my records...  i'm
treading into data incongruity waters best tread by an ORM if i want
to keep things simple.  but zope3 doesn't really "do" that. 
sqlalchemy and sqlobject/sqlos do, and those are excellent options...

but for me it begins to beg the question.  i'm storing my data in two
places because the zodb can't/won't give it back to me easily?  and
dangerously comes the day that i realize somewhere, somehow, my data
has gotten out of sync.  or worse yet, a redesign of a class suddenly
has my data held elsewhere.  the object mapper is persistent too, so
if the table or the class design changes, i don't just update data,
update methods, and forget it...  i have to update persistent objects
that are mapped elsewhere too.  it's sticky.  i'm not saying it isn't
doable.  it certainly is, and i've even taken shots at doing it, on a
small scale, for a recent project i was on.

but it just seems like an overly complicated way to do things...  here
i have my zodb where i'm going to store my persistent objects.  over
there i have relational data.  needing both, i understand, if they
hold different kinds of data.  but if the only reason i need two
places to store things is because i can't get at my data in one of
them, or if i need to build objects in zope3 that don't use the zodb
just because i can't get at them other than programmatically, then it
makes me wonder why.

just my thoughts on it...

On 4/23/06, Chris McDonough <chrism at plope.com> wrote:
> 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
> >
>
>


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