Re: some MDB2 questions

Lukas Smith wrote:

What about the API - is it in sync with PDO now? I think PDO API is finished / beta since yesterday, right?

There are still some thing left. Mainly that PDO has a single class for results and prepared statements, option handling, metadata fetching.

Will this possibly be changed? I don't see advantages to have only one class for all of these. And I also don't understand the sense of $stmt->bindParam(':foo', $bar); ;-)

But it's nice to check if there is for example only exact one line or no line returned from database.

But you can do the same if you fetch the first 2 rows or the entire result set.

But IMO it is nicer to write if ($result->numRows() == 1)... instead of something like if ($result->fetchRow() && !$result->fetchRow()) ... I don't use this for large result sets.

For mysql this seems to be a free check, but this is only due to the fact that most people use mysql_query() which actually buffered the entire result set in the client.

does MDB2 need an extra request to the DB-Server if I use numRows()?

[autoExecute()]

Personally I dont care for these methods inside MDB2.

But for me again it is nicer to write $data = array ( 'col1' => $val1, 'col2' => $val2, 'col3' => $val3, ); $db->autoExecute('table', $data); So I don't have to mess with SQL here, and I can use this code easily for updates too. I don't have to care for quoting...

Which admittedly is the reason I moved them into the extended module

Hm, $db->extended->autoExecute() is not so nice to use ;-) Isn't there a nicer possibility to use $db->autoExecute(), perhaps by subclassing? Perhaps the factory could get a parameter to return the "extended" class?

since they are too high level for an abstraction layer imho.

But where should something like that be implemented? If the database becomes more complex, I don't like to use things like DB_DataObject, because it becomes unflexible for selects with some joins, groups... And to implement DAOs, object-relational patterns is also difficult with complex data, and needs a lot of work and performance, especially due to PHPs "no state between requests". So in my eyes autoExecute() provides a very nice, intuitive way to manipulate data.

However if your implementation works just as well functionality-wise I will be happy to add it.

for ADOdb I removed autoPrepare() (because I cannot see any sense in using it ;-)) and buildManipSQL() (because I implemented its functionality in a simpler way, which was only needed by autoExecute()), so I only had a simple autoExecute() methode which used prepare() and execute(). I used both versions, the one John has put into ADOdb 4.60, and mine, without any problems (there were some small errors in my posting from adodb forum). I tried to switch from PEAR::DB (where I used autoExecute() a lot) to ADOdb, and after autoExecute() was implemented, I could use ADOdb (after some replaces in my scripts) without any wrapper. I think autoPrepare() is needed for compatibility-issues in PEAR, so I only changed buildManipSQL() to get no duplicated code. I did not change the signature, only the implementation - but as said - not tested in MDB2.

If you know frontbase or mssql feel free to send in patches :-)

I'm sorry, I don't use any of these and I don't think I will need it some day ;-) If so of course I will try to help out. Perhaps some day I need DB2, but at the moment I have no DB2 installation. How mature is the MySQL reverse-engeneering script today? What happends to MySQLs "sequence emulation tables"? regards, Andreas