I only mentioned XPath (I meant XQuery) in reference to native XML
databases.
As for Dbm, the idea was to use the native libraries so you get
transactional support if available (which the PHP package does not support),
and if the specific library wasn't available it would use the "baseline" PHP
functionality.
-Matt
----- Original Message -----
From: "Bill Karwin" <bill.k-C1q0ot2/XZ0@xxxxxxxxxxxxxxxx>
To: "Matthew Ratzloff" <matt-+P5+TSubNX2aixswqVHUqUEOCMrvLtNR@xxxxxxxxxxxxxxxx>
Cc: <fw-db-wwOhfgvld6hpLGFMi4vTTA@xxxxxxxxxxxxxxxx>
Sent: Sunday, December 10, 2006 3:04 PM
Subject: Re: [fw-db] Non-SQL databases and the Zend_Db namespace
We currently have an XML solution in incubator/Zend/Db/Xml/Xml*.php.
Right now, the Zend_Db component assumes a SQL interface is the norm. I
don't want to introduce further complexity by moving the Db classes down a
level in the package space. The Zend_Db_Xml classes are different, they
do not seem to supply a SQL interface. But they live under the Zend_Db
package space anyway. I think other non-SQL data access classes could do
that too.
By the way, why would we need an Xpath component in ZF? PHP already
includes several mechanisms to use Xpath. It also has a DBM abstraction
layer. We have turned down other proposals for components that simply
duplicate or wrap existing PHP functionality without providing some
compelling added value.
Regards,
Bill Karwin
Matthew Ratzloff wrote:
Hi everyone,
Currently I'm in the process of writing up a simple proposal for
Dbm-style databases (Berkeley DB, GDBM, etc.). The description for
Zend_Db and Zend_Db_Adapter_Abstract both say, "Class for connecting to
SQL databases and performing common operations." But there are other
types of databases besides SQL: key/value pair (Dbm-like), XPath-based,
object-oriented, and so on.
So where do the adapters for the other types of databases go if not
Zend_Db? If someone wanted to create a read-only dBase adapter, where
would it fit? Creating multiple top-level namespaces is sloppy from an
organizational point of view as well as unintuitive for users. For that
reason I propose that the current Zend_Db_* hierarchy move to
Zend_Db_Sql_*. This way, we can keep abstract functionality in logical
places: Zend_Db_Xml_Adapter_Db2 (IBM DB2 9), Zend_Db_Xml_Adapter_Berkeley
(Berkeley DB XML), Zend_Db_Dbm, etc.
It might be a bit painful to do now, but I think the need will come up
again later. If it's closer to 1.0 then it will be much more painful.
Thoughts?
-Matt
|
