Subject: Response to Article on ACS x Zope
From: <[email-masked]>
To: <[email-masked]>
Date: Thu, 15 Jun 2000 16:13:13 +1000

Albert Langer ([email-masked]) responded to a message
you
requested notification for in the OpenACS compared to other toolkits and
technologies bboard:

Subject:  Response to Article on ACS x Zope

[CM]
There is no SQL abstraction layer in Zope like Ben's talking about.  You
still
need to write DB-specific SQL to gain results out of a query.
To my knowledge, the only system that abstracts this layer out well is
Apple's
WebObjects which I believe can use Oracle, Sybase and Informix as its object
persistence layer without requring that you  write any SQL.  We don't do
this.

We instead use the ZODB as our object persistence layer, and we let people
connect to RDB's and use that RDB's specific set of SQL commands.  To get
anything useful out of the RDB's, you need to write system-specific SQL.

[AL]
My understanding is that Ben is talking about something quite different from
WebObjects.

To clarify that, I have posted some notes about Web Objects in a separate
topic, "Apple WebObjects", on this bboard:

http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0000Hi&topic_id=8&top
ic=OpenACS%20compared%20to%20other%20toolkits%20and%20technologies

Can we all agree that something like WebObjects is beyond the scope of what
OpenACS is after for data abstraction and beyond the scope of what Zope
intends to provide?

>From my perspective the use of ZODB as an object persistent layer is fine
for many things but completely unacceptable for Ecommerce OLTP transactions.
For those you need not only to get things out of RDBMs, but also put them
into RDBMs and the application is really an RDBM application.

I don't buy the idea that Ecommerce based on ZODB alone without an RDBM is
viable, for reasons explained in 1) and 2) of:

http://lists.codeit.com/pipermail/zcommerce/2000-June/000257.html

BTW If you are aware of anybody else attempting Ecommerce OLTP with an
OODBMs please provide a reference. Otherwise please confirm that Zcommerce
efforts to do so using ZODB without an RDBM should be considered
"experimental".

Despite that, I still believe Zope could be useful together with an RDBM
based Ecommerce module and I am interested in whether it is possible for the
existing ACS Ecommerce module to be made more "stand alone" and used with
both OpenACS and Zope, or whether development would inevitably need to
"fork".

I claimed that:

For access to RDBMs databases via SQL, Zope provides pretty much exactly the
sort of data abstraction facilities that Ben was talking about in:
http://openacs.org/doc/sql-abstraction.html

Based on that view I am proposing that OpenACS people and Zope people should
get together in work on data abstraction.

Your comments below, and those from Jimmie Houchin, seem to indicate that
I'm wrong about that.

Given that you know far more about Zope than I do, I'll have to accept your
view. But before abandoning the idea I'd like to get it clear whether we are
really talking about the same thing.

[CM]
Zope does abstract out the ability to process results of SQL queries.  If
you've got a Zope system with connections to different databases (for
example
if you're grabbing stuff out of an Oracle DB and a Postgres DB within the
same
Zope instance), you create database connections to the two DB's, you create
"SQL methods" for each query for each DB, and then in Python or DTML you
pass
arguments in to the "SQL method" that houses each query, and you can process
its results generically.  You needn't worry about where the data came from.
Here's an example:

SQL method "getstatus" query:

SELECT status
FROM customer
WHERE id = <dtml-sqlvar custid>

DTML method to process the results from this query:

Customer status:  <dtml-var "getstatus(custid=1)">

The DTML method passes the value of custid in to the SQL method, gets the
result back, and displays it.

This is the extent of Zope's SQL abstraction.  You can process query results
independent of the data source by creating a "database connection" to a
specific DB (Oracle, Postgres, MySQL, Solid, ODBC, and Sybase) then creating
"SQL methods" against these database connections that accept arguments and
return results.  The content of the SQL methods is necessarily database
specific.

[AL]
Above is my understanding of what "Z SQL" offers.

But I thought the "Dynamic Data Objects" were intended to provide rather
more.

Could you please comment more specifically on the following excerpt from my
previous posting and explain what I have misunderstood:

**************
The next level currently requires some vOOdOO to understand "ZPatterns". See
especially the section on "Dynamic Data Objects" in the contents map at:

http://www.zope.org/Members/pje/Wikis/ZPatterns/HomePage/map

Suffice to say that it is NOT one of the three options that are possible
without "very OO database OO" but a fourth option made possible by OO. Yes,
you
still need RDBM specific (or site specific) SQL for optimization, because
there
is NO WAY that can be avoided. But it hides this behind umpteen layers of
framework code so that it is completely insulated from the application
domain
queries and updates and UI templates written by non-SQL developers. This
makes
life much harder for people implementing the framework (ie core Zope
developers), just as life is hard for people writing the internals of
Postgresql. But it makes life much easier for people customizing UIs, people
customizing queries and updates based on application domain models and for
people optimizing RDBMs engine access, because they can all keep out of each
other's way. (If it's the same bunny doing them all, at least they can think
about just one thing at a time).

***************

What I had in mind is that Ben's document refers to a simple template for
inserting parameters, into SQL much like what "Z SQL" provides, but with
tags like {Oracle, Postgresql} which indicate whether a particular SQL
statement is suitable for use with a particular RDBM. This would simplify
maintenance of multiple ports by reusing whatever can be reused and
providing sufficient isolation from the rest of the application for SQL
development and Tcl development to be less tightly coupled.

It seemed to me that although the "ZPatterns" framework is currently used
only for multiple login authentication (eg from LDAP directory or RDBM
instead of Zope folders in the ZODB), it is intended to be far more widely
applicable and could be used to provide data abstraction of the sort Ben is
after, by people who understand the problems of porting between different
RDBMs as well as for providing application Domain Models, Roles and facades
for people using the ZODB.

-----------------

To post a response, come back to the bulletin board at

http://openacs.org/bboard/q-and-a.tcl?topic_id=8&topic=OpenACS%20compared%20
to%20other%20toolkits%20and%20technologies

-------------

If you are no longer interested in this thread, simply go to the
following URL and you will no longer get these notifications:

http://openacs.org/bboard/shut-up.tcl?row_id=1488768

-------------

Note:  this message was sent by a robot.