[Zope3-Users] Re: zql

Mon Apr 24 18:51:31 EDT 2006

Please make an effort on behalf of your readers and put an initial 
uppercase at the start of your sentences. They exist for a reason: 
readability. You brain dump below is pretty hard to understand.

On the topic though: what you need is a view to an RDB through zope. You 
can do that through an ORM using something like sqlos, or you could do 
that through a mountpoint that synthesizes objects (also through an ORM) 
using a different connection class to persistent objects, like Ape does.

I've been toying with an SQL mountpoint based on SQLAlchemy, it's put on 
hold for now but I hope I'll be able to get back to it.

Florent

Pete Taylor wrote:
> 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-ccARneWBNkgAvxtiuMwx3w at public.gmane.org> 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-CWUwpEBWKX0 at public.gmane.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

-- 
Florent Guillaume, Nuxeo (Paris, France)   Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   fg at nuxeo.com