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
> >> 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
> > Zope3email@example.com
> > 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
Zope3-users mailing list