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
|
