Re: DB_Table: Summary and Pre-Call

Hi, Please allow me a bit of ranting. It is kind of hard to see this discussion taking place all over again, when I already proposed DB_OO back in December. DB_OO back then did most of the stuff now present in DB_Table, with only slight variations in approach (and better documentation, if you allow me some ego polishing). I agree that there is an aproach to database interaction not fullfilled by any of the current Pear packages. PHP is, after all, a scripting language, with a very rapid development cycle. Pear should provide packages that exploit this ability to quickly have programs up and running -- even if also providing packages aimed at true OO application designs. DB_Table, DB_OO and DB_Dataobjects all provide a poor-man's abstraction layer, that directly mimics the relational structure. DB_Dataobjects, however, seems to me the wrong approach for a poor man's abstraction layer. Requiring configuration files, even if generated, introduces overhead in the 'change code-test-change code-test' development cycle undesired in RAD. I'm in no way downplaying DB_Dataobjects value. It's that I feel this package will evolve into something like Castor. In this scenario DB_Dataobjects and DB_Table don't compete. So, to end my rant: I like DB_Table's approach, and I think it fills a need in PEAR. Most of the stuff is written just about the way I'd do it. I just have two showstoppers and one big question: 1) I'd prefer if the datatypes were based on an SQL standard. From the SQL92 standard, these would be: CHARACTER, CHARACTER VARYING, BIT, BIT VARYING, NUMERIC, DECIMAL, INTEGER, SMALLINT, FLOAT, REAL, DOUBLE PRECISION, DATE, TIME, TIMESTAMP, and INTERVAL. 2) At least these datatypes should be stored as native datatypes. When aiming at interoperability, the best is to aim at implementing a standard. I definitely reject the idea of having dates stored as CHAR or VARCHAR. Most databases have the ability to do powerful date arithmetic. There is no point in throwing all those reliable, fast and proven functionallity out of the window in name of interoperability. 3) Having DB_Table tested only with mySQL, I don't think the interoperability has been put under stress. Are there any design assumptions that will need to be revised in order to have it work with other DBs? mySQL has a very poor SQL92 implementation, with largely different datatypes. I'd feel more confortable if DB_Table had been approved for use with pgsql or oracle. So, for me, it's a conditional +1. Cheers, Sérgio Carvalho Paul M Jones wrote:

Hi, everyone, DB_Table has been in proposal since Jan 4 (that's four months almost to the day) and has generated some interesting comments, some positive and some negative. At this point, I have added to it everything I originally wanted, and some things I discovered were useful along the way. If you are not familiar with the proposal, please take a look at the PEPr site.

    http://pear.php.net/pepr/pepr-proposal-show.php?id=14

The highlights are: * Extend the DB_Table class (no external config files needed), * Build a table schema within the class to define columns, indexes, and form elements, * The first time you instantiate the class it automatically creates the table for you, * Build SQL queries that you can then filter and call with ::select() and ::selectResult * Call ::insert() or ::update() and it automatically validates the data per the table schema, * Call ::getForm() to build an HTML_QuickForm based on the table schema. ---- Earlier discussion pointed out that DB_Table might best be part of the DB package. However, Daniel Convissor has more and better things to do with his time than add somebody else's files to the DB package; the DB code as it stands now is more than enough to take all his attention (and he's done good work, too). Daniel has encouraged me that DB_Table should be its own thing, not a part of DB (if for no other reason than lack of time to evaluate it). As such, I'm ready to set PEPr into "call for votes" mode on DB_Table, as a package of its own (not part of DB). I know at least one pear-dev lister (hi Lukas!) doesn't like that idea, for a number of valid reasons; among others, he thinks that DB is the past and MDB2 is the future, and that there are enough packages with DB_Table-like behavior in PEAR now (e.g. DB_DataObject). Lukas also points out that the future PHP-native dbx library and the future DB_Schema package should solve the concerns addressed by DB_Table, but he agrees that these future solutions do not help us right now. Alan Knowles also had valid objections, primarily that his DB_DataObject package works in a manner similar to the proposed DB_Table; however, I think his opinion may have become more moderated of late. Perhaps I am wrong there; Alan, are you still against DB_Table being in PEAR? (My argument on this point is based on the fact that DB_DataObject and DB_Table make different tradeoffs between structure, reusability, and distribute-ability of the resulting classes; this difference in balance is not bad either way, they just serve different audiences and purposes.) Way back in October, Alexey Borzov didn't like the "poor man's data type abstraction" that DB_Table uses, and I don't expect he has changed his mind. Other than that, I have received a small amount of good feedback, but not on the list; it has been addressed to me privately or in the comments on the DB_Table documentation site. So that's it; unless I hear (and agree with ;-) valid and serious negative comment on DB_Table, I'll call for votes and the whole thing can be finished. Thanks to everyone for their positive and negative feedback.

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc