Re: some MDB2 questions

Andreas Korthaus wrote:

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); ;-)

Well i am following the PDO API. And I have told Wez that I dont think this is a good idea. So it goes. As for the bindParam(). Look here: http://de.php.net/manual/en/function.pdostatement-bindparam.php

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.

Course its nicer looking. I am just saying its definately not faster in most cases.

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()?

No. For buffered resultsets this is all handled inside the client.

[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...

Sure. I can see how its useful. However it seems to me like then you might as well use a "true" OO interface to your data.

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?

I will add something (atleast for PHP5) that will get around this using __call() so that you dont have to type that extra "->extended" and you dont even explicitly need to load the extended module.

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.

I can see where you are coming from. Once __call() is in there all will be nice.

How mature is the MySQL reverse-engeneering script today? What happends to MySQLs "sequence emulation tables"?

Quite mature. I think it screws up with multi column unique indexes. Aside form that it works very reliable. There is a little helper script in the package in the MDB2/Tools dir. The trick is of course that its not always possible to know exactly the type. For example CHAR(1) could be text or boolean etc. In that case MDB2 picks the more likely one and raises a warning for all the other possibilities. regards,