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 > > [email protected] > > 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 [email protected] http://mail.zope.org/mailman/listinfo/zope3-users
