• Add query logging/profiling (also something like http://blog.talbott.ws/articles/2006/05/17/querytrace-my-first-official-rails-plugin ?)
• Remove Horde_Rdo::CUSTOM, allow custom 'query' arrays on all relationships as possible, and have a new type (not relationships, but mixins? extra_fields? that can be defined by a Query and that allows the flexibility of CUSTOM without being smooshed into relationships.
• Allow Horde_Rdo_Query objects to be turned into just WHERE (or JOIN) clauses
• Allow relationships to be defined by Query objects?
• allow for using php.ini-set database configs for security, or perhaps $ENV variables - see Ilia's security presentation. Example php.ini dsn: [PDO] pdo.dsn.MYDB="odbc:SAMPLE"
• Ensure that Rdo_Base objects are serializable
• Charset support: support a database charset config parameter, and convert field values to the requested client charset.
• Implement named queries (http://www.tonybibbs.com/article.php/PropelDAO)
• Support composite primary keys. Discussion of surragate vs. natural primary keys: http://www.bcarter.com/intsurr1.htm
• Saving arrays, hashes, and other non-mappable objects in text columns ?
• Allow setting $key field explicitly (not just by overriding the model)
• Some check for whether or not an object is new (has been saved to the backend yet)?
• Freezing: implement $frozen variable for Rdo objects for when the object has been deleted, or similar?
• Caching hooks - not required, but allow caching of models, query generation, etc. with a passed-in Cache object.
• Work on the basic Horde_Support_Inflector enough that it supports standard Horde table naming.
• Use fetchObject (at least in PDO drivers) for performance?
• Eager loading of MANY relationships - see http://darwinweb.net/article/Optimizing_And_Simplifying_Limited_Eager_Loading_In_Activerecord
• Two-query eager loading of a specific relationship (load the main object in one query, then all foreign-key objects in a 2nd, and join the two.
• Implement eager loading with several relationships to the same table.
• Observer hooks: beforeDelete, afterDelete, beforeUpdate, afterUpdate, beforeCreate, afterCreate
• Support fixtures (YAML?) for testing
• Test suite for Rdo: http://www.ds-o.com/archives/64-Adding-Database-Tests-to-Existing-PHPUnit-Test-Cases.html http://mikenaberezny.com/archives/79 http://www.phpunit.de/browser/phpunit/branches/3.2/PHPUnit/Extensions/Database/Operation

Links: http://www.analysisandsolutions.com/code/dates.htm http://www.qcodo.com/ http://dev.mysql.com/doc/refman/5.0/en/example-maximum-column-group-row.html http://www.phpdoctrine.com/ http://www.artfulsoftware.com/mysqlbook/sampler/mysqled1ch20.html http://www.analysisandsolutions.com/presentations/portability/slides/toc.htm http://fuzzyblog.com/archives/2006/08/12/sql_calc_found_rows-and-faster-count-alternatives/ http://phplens.com/phpeverywhere/?q=node/view/231 http://pooteeweet.org/blog/688 http://pooteeweet.org/blog/711 http://pooteeweet.org/blog/809 http://schlitt.info/applications/blog/?/archives/528-Object-relation-mapping-in-eZ-Components.html http://nubyonrails.com/articles/2005/12/27/dump-or-slurp-yaml-reference-data http://db.apache.org/ddlutils/ http://www.thespanner.co.uk/2007/07/23/php-mysql-tips/ http://www.sqlalchemy.org/

things that can be specified on relationships: className - only if it can't be inferred from the field name foreignKey - also if can't be inferred criteria - restrict associations by more than foreign keys dependent - if true, associated object is destroyed when main object is order - of associated objects?

• cascading deletes/updates: ?
• Single table inheritance ?

class Company extends Rdo
class Firm extends Company
class Client extends Company
class PriorityClient extends Client

CREATE TABLE companies (
  id int(11) unsigned NOT NULL AUTO_INCREMENT,
  client_of int(11),
  name varchar(255),
  type varchar(100),
  PRIMARY KEY (id)
);

CREATE TABLE people (
  id int(11) unsigned NOT NULL AUTO_INCREMENT,
  name text,
  company_id text,
  PRIMARY KEY (id)
);

potential field parameters: size maxsize fixedsize numeric null canbenull default canhavedefault unsigned canbeunsigned realname description type base

>> Here I disagree. To me the key point of a DBAL compared to just a DBL (database layer) is that it provides almost everything necessary to manually build portable SQL. This means that instead of passing of an array that magically builds my SQL, the user remains in the driver seat and is provided with a rich enough API to build almost everything in the SQL spec (and a bit beyond that) in a portable manner.

> What you want to say is that a DBAL must additionally provide: > a Query Builder, maybe extendable by the driver to provide RDBMS specific options/methods

no .. not a query builder .. that would imply that you just pass of some data and it magically constructs the entire SQL for you .. that is the job for some OO<->SQL tool. what I think a DBAL should provide is methods to generate pieces of SQL that are then assembled by the user.

so for example setLimit() would either return or automatically append to an supplied SQL string. same applies to field abstraction, you still call quote() to get the necessary SQL fragment to embedd in your SQL statement.

Pierre Minnieur wrote: > Must a DBAL then provide OO access to executed statements, prepared statements and results sets, too (like PDO does)?

absolutely .. a DBAL also needs to cover the reading part. so you need to have a portable way to read data from the database (including data type abstraction, handling of trimming off empty spaces etc).