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.


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 <[EMAIL PROTECTED]> 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
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
like AdvancedQuery to specify almost generic queries for the
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.

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

"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   [EMAIL PROTECTED]
Zope3-users mailing list

Reply via email to