Re: New PDO-based DBAL/ORM for PEAR2

On Nov 20, 2007 6:47 PM, till <klimpong@gmail.com> wrote: > > On Nov 20, 2007 5:10 PM, Alexey Borzov <borz_off@cs.msu.su> wrote: > > Hi, > > > > > > Lukas Kahwe Smith wrote: > > >>> Please feel free to check out the code if you'd like to try it out or > > >>> provide encouragement/suggestions/criticisms. The code is hosted on > > >>> Google code, so bugs can be reported on the issues tracking system > > >>> there (until it's ready to be voted on for inclusion in PEAR). Also, > > >>> I'll be maintaining a wiki at that site that will contain details on > > >>> how to use the package. I'd like to get a lot of people testing out > > >>> the package and posting questions to the wiki so we can get a good > > >>> idea what information the docs need to contain. Once we get a good > > >>> set of wiki pages, it will be easy to port the content they contain > > >>> to DocBook format. The package is very well documented and should be > > >>> fairly easy to understand for anybody who's familiar with MDB2 and/or > > >>> PDO. > > >> > > >> It looks good. I personally would remove the datatype and manager > > >> stuff, as well as most of the things related to SQL abstraction since > > >> this is a myth and adds bloat in the package (sequences and dates to > > >> start with). I'd call Drivers -> Connections and remove the singleton > > >> method. I wouldn't make a difference between one-to-one and > > >> one-to-many relations. I don't > > > > > > Funny that I managed to port my CMS from MySQL to PostgreSQL in 2 hours > > > (mostly fixing reliance on non deterministic group by's) and to SQLite > > > in 3 hours (1 hour was used to add a feature to handle the fact the > > > SQLite by default qualifies joined columns with the table name unless > > > aliased) as it was based on MDB2. I should also mention that the > > > installation tools based on MDB2_Schema needed no alterations. I also > > > did not feel like I was artificially limiting myself. For example one > > > thing that did require custom code was the internal search, which was > > > based on MySQL's FULLTEXT indexes. But that was a minimal amount of work > > > and a tiny addition to the code. Just to set the record straight. > > > > Porting something *from* MySQL isn't an impressive feat, due to its limitations. > > Now if your abstraction layer allowed porting an application written and > > optimised for Oracle (or PostgreSQL) *to* MySQL in 2 hours, that'll be something > > to be proud of. > > > > Going for "database abstraction" is IMO an extremely bad thing, since it > > encourages coding for the Lowest Common Denominator (MySQL / SQLite). Of course > > having an unified API for fetching the rows helps a bit, but the underlying > > logic should be written and optimised for each DBMS, not written for MySQL and > > ported everywhere else as an afterthought. And that means hand-tuned separate > > schemas, not a dumbed-down schema meta-language. > > Correct me if I am wrong, but you could still write your > *whatever-specific* code and fire it up through query/exec and deal > with it yourself. I mean, I like MDB2 not because my apps are > constantly deployed with different backends (even though I have > clients who use the same app but run MSSQL, Postgre, SQLite and MySQL) > but the beauty lies within all the shortcuts. > > In general, and this is not meant to offend anyone (!), but all the > opinions on DBALs should probably not be a part of this thread. Too > many people already agreed that we want this in PEAR so let's discuss > the use of DBALs (and if they suck, are bad and whatever) somewhere > else. We are after discussing DBALs and ORM now but the structure of the code :) I agree with Alexey a bit in saying that each RDBMS has to be hand tuned, but Alexey, the DBAL in this case is to establish a standard way of doing things instead of using the native methods and different ways of doing each time. Just like a website, you can build it with tables and ugliness but it's not standard and people will not want to work with that. Anyways, I am getting a bit too far into the DBAL subject again. Michael, "PDO is the way PHP is getting?" I'd sure love to see that but I'm sorry that the numbers say something else: PDO statistics: 104 692 downloads http://pecl.php.net/package-stats.php?pid=335&rid=&cid=7 MDB2 statistics: 384 232 downloads http://pear.php.net/package-stats.php?pid=279&cid=7 And more ? Some software have MDB2 bundled. That's just about the same date range. Core devs would sure love to see PDO be used everywhere but that's only a wish. People try people try but the fact is that PDO is not the general direction. All this to say one thing, you need to support more than only pdo in that package otherwise you'll only reach exactly that, 25-30% of the developers and companies out there. P.S. Oh yeah PDO is written in C ? Man that must be why it's so fast.. > > I look forward to seeing this package in PEAR2, I'd just vote for an > easier name. :) > > Till > > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > Anyways for PEAR2 you'll need to read this:http://wiki.pear.php.net/index.php/PEAR2_Standards For your mssql driver: - in listTables, you should use: EXEC sp_tables @table_type because sysobject is not compatible with all the versions.It's ok for listTableFields though. (Why is my name not there? From what I see it's code that I have written as well ;-) - just kidding) ref: (http://pdorm.googlecode.com/svn/trunk/PDORM/Connection/mssql.php) - I would probably remove listUsers(). It could be a security problem. Not everyone knows how to query the master table, let's keep it that way :) (I'd personally remove it from MDB2 but that's a team decision) ref: (http://pdorm.googlecode.com/svn/trunk/PDORM/Connection/mssql.php) - PDORM_Function::concat() in the mssql function I would add a $separator variable that lets the user concat with their favorite separator. I can easily see someone querying firstname, lastname and concat'ing it to TRIM(FirstName) + ' ' + TRIM(LastName) or some might even want ,-+. ... who knows. ref: (http://pdorm.googlecode.com/svn/trunk/PDORM/Function/mssql.php) - I'm not sure if the whole PDORM_Domain_inflector is such a great idea (for this package don't get me wrong). But to me it doesn't belong in that package at all. Another package ? Sure, but not in there. ref: (http://pdorm.googlecode.com/svn/trunk/PDORM/Domain/rules/en.php) - Argh! Mapper.php, please handle what is wrong, don't just ignore it... @ is slow as hell anyways. ref: (http://pdorm.googlecode.com/svn/trunk/PDORM/Domain/Mapper.php) - I love listeners, good idea. - I cannot seem to see LOB handling and Iteration through resultset ? Is that on purpose ? - Your Exception class is great, a bit of clusterf*ck but quite cool to give better error messages. - PDORM.php's factory() is imho WAY too dependant on PDO itself. I think this should go in a different "File" in a way that people can easily make their own drivers. You shouldn't have to change the factory like you are going to kill the president and setup an attack plan for months. It should be trivial imho and set your attribute in your "driver's" factory. I have more but I have to get going. Else than this good job, it's quite clean. Actually if you have a mssql server online I could help you with that part (mine's been down for a while), I could even makes a few fixes and tests on MDB2 since I am just about good for a release soon ;-) -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18