Re: The future of database packages in PEAR

David Morse wrote: Hi,

There is a problem of complexity: The entire package looks well designed, but it takes some time to get your head around. It would be difficult to learn the entire public API. The size of the API is a potential barrier for more casual or impatient users. This barrier could be reduced if an influx of new developers and users helped write tutorials with relatively simple usage examples. It is also true, moreover, that most of the basic functionality provided by MDB2 alone is provided by PDO, which has a relatively simple API.

This package should be split up as much as possible into subpackages. This will make it much easier for developers and users.

based on abstract data types. The MDB2 Manager and MDB2_Schema classes also provide reverse-engineering of table schemas. (I should mention that table modification is inherently more complicated in a database with foreign key relationships, since you have to make sure that the PHP database model remains sane and accurate when tables are modified. This is something that I haven't fully grappled with in DB_Table_Database.) If Doctrine does not contain as rich a

The same applies to views and stored procedures. The good news is that none of these hold any original data. As a result you essentially you have two options 1) create a dependency graph and work accordingly 2) replace all of these trouble makers with dummies, who are replaced at the very end. so essentially you remove all objects with dependencies and replace them with empty implementations (a view could be turned into a dummy table etc), do all changes that add/remove/change database objects and finally you replace the dummy view with the real one. this is what mysqldump does for example.

One weakness in the current PHP 4 MDB2/DB_Table stack of classes is that the MDB2 and DB_Table abstract data types were defined independently, and are not entirely consistent in either choice of what types to support or how they are stored in different databases. (MDB2 makes more use of native data types, while DB_Table tries to store some things like dates and times in the same way in different RDBMS, using more primivite types). While this has been worked around in the current version of DB_Table, it is something that IMO would be important to fix during any simultaneous PHP 5 rewrites of both packages. More generally, if development of MDB* and MDB*_Table continues, it will be important to try to make the two packages more coherent. One signficant advantage of Doctrine is that it was designed as a single coherent application. A similar level of coherence could be achieved by a simultaneous PHP 5 update of MDB2 and DB_Table, but I don't think it exists yet.

I have added abstract datatypes in MDB2, which will be added to Doctrine in some way or another as well. Essentially this allows people to define custom callbacks, so that they can define types like "email" that contain validation if they want. In MDB2 it only works with a 1-1 mapping between value and database field. It would obviously be cool to be able to automatically split data into 2 fields (like storing a timezone in a separate column for rdbms that do not support timezones in timestamps).

get this clarified. If Doctrine doesn't include a way to specify returned data types from queries, it is something that should be considered for addition.

yeah .. but it should have sufficient information todo so ..

clause involves only a series of column names. If the select clause involves expressions or SQL operators, however, it becomes impossible to do this without parsing and analyzing the SQL.

yeah .. in that case the users has to either explicitly tell you .. or use some abstraction to build the expressions which would then also give you a way to figure out the returned data type.

In Doctrine, queries can be submitted in a Doctrine Query Language (DQL) that appears to be, essentially, a dialect of SQL, with a very concise way of specifying when known relationships should be used to construct joins. This is silently parsed and internally converted to the appropriate SQL dialect for the backend RDBMS.

FYI: its inspired by HQL aka Hibernate Query Language.

Aside from this, how does Doctrine deal with enforcing foreign key integrity? Are foreign key constraints declared in the create table statements, so that they can be enforced by the RDBMS (if supported?) Are foreign keys checked at the application layer upon insertion and updating? If a row that "has" (rather than "owns") another is deleted, is anything done to the referencing columns? What (if anything) is done to referencing columns upon updates of referenced keys?

I dont know this either. But the aim must be to do a maximum of integrity checking in the database. The main reason for this is not really performance, but the simple fact that it makes it easier for DBA's to work directly on the database and it also makes it easier to work in hereogenous environments with other languages.

XML ---- The documentation for Doctrine emphasizes that configuration of a Doctrine application is not based parsing XML configuration files. Aside from initial configuration, however, XML or some other text format has an important role as a way of communicating a database schema between applications or packages. If, for example, we have form-generation packages separate from Doctrine or MDB2/DB_Table or DB_DataObject, the form generation package will need a format from which it can extract a table or database schema. Similarly, if someone wants to port an application from MDB2/DB_Table to Doctrine, it would be nice if there were a common format for the database schema that one application could output and another could import. If MDB2_schema has the ability to reverse engineer a schema, and Doctrine does not, it would be nice if they could talk to one another. In writing DB_Table_Database, I tried to adopted the MDB2 XML syntax. Igor Feghali and I have now agreed on a syntax for foreign key constraints, which weren't supported by the MDB2 DTD. It might be worth thinking about adopting this or another XML dialect that supports foreign keys as a sort of standard for communication between packages, or at least adding methods to Doctrine to export and import database schemas in some existing XML dialect.

XML is just a serialization format. To me the key point is to support a php native format (array, array of objects etc). Once this is defined you can easily write generators that allow reading/writing of other serialization formats as needed. XML has some definate advantages as a serialization format.

Transactions ------------- It appears from the documentation that Doctrine wraps all SQL commands in transactions. If an application issues a series of several related commands, and the programmer wants to wrap the whole sequence in a transaction, will this interfere with the automatic use of transactions, i.e., is it easy to wrap user defined transactions around ones that Doctrine is using internally? How is this done?

Not sure either. For one Doctrine has taking the nested transaction code from MDB2, which should make this possible. BTW: Konsta was busy with exams this week. Not sure if he is done with them yet .. regards, Lukas