hmmm... i don't guess i disagree with those contentions directly, as
they apply to sql. but i do think that a query language of some kind
for the zodb would be beneficial. i have already encounted user-realm
questions on applications i've built that would be more easily
answered with a query language, rather than specific python scripts or
catalogs. the trouble with catalogs is that until you know you're
going to want to index on and query certain information, you probably
won't build an index for it in the catalog... and it's a non-trivial
amount of work to make querying the zodb, even with hurry.query, work
the right way.
but lets say i have a customer that says "hey pete, our application
has been installed and running fine for the last three months... but
now we'd like to pull a list of every order/person/whatever that
matches criteria 'x', but not 'y'?" that means i'm writing a python
script for it. and it's not sustainable or maintainable... if i want
to pawn off the running of queries on my application to a jr.
developer, or i want to teach a non-python technical person how to get
information out of the zodb, right now, i can't do it...
we build apps in j2ee, but we don't expect our oracle dba's to be
proficient in java. similarly, if zope3 is going to spread to the
enterprise, there needs to be a way to access data in the zodb that is
more similar to something my user community already knows how to do.
i could teach a dba and a jr. dev to use a sql/oql derivative. it
"looks like" something they've seen before. and while i might be the
first one to argue that everyone should know python, i can't
realistically enforce that ;)
i'm not stuck on my own idea though... if there are other ways of
accessing data in the zodb that don't require extensive knowledge of
python, then i'm all for knowing about them and teaching my technical
dept. how to use them...
On 4/23/06, Andreas Jung <[EMAIL PROTECTED]> wrote:
> --On 21. April 2006 11:03:48 -0400 Pete Taylor <[EMAIL PROTECTED]> wrote:
> > i'm going to call a zodb query language zql for now, because i like it
> > and think it's catchy ;) ...i know there's a java query parser called
> > "zql" also, but i'm not proposing a formal name, so i'm going to use
> > it anyway. i'd think of zql as just an OQL specific to the zodb.
> A long time ago Stefan Richter has written something similar for Zope 2
> (can't remember the name)
> > zql> select * from myobj;
> > zql> grant all on mycontainer.* to 'email@example.com;
> > zql> grant zope.View on myothercontainer.* to 'firstname.lastname@example.org;
> > zql> commit;
> Why do you think it would be necessary or helpful to define a SQL dialect
> (which is designed for a relational data model and not for an
> object-oriented model)? The usecases for SQL are different from the
> usecases when you deal with the ZODB. I doubt that are benefits for
> real-world apps for such an approach.
> ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany
> Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376
> E-Publishing, Python, Zope & Plone development, Consulting
"All guilt is relative, loyalty counts, and never let your conscience
be your guide."
- Lucas Buck, American Gothic
Zope3-users mailing list