Re: New PDO-based DBAL/ORM for PEAR2

On Nov 20, 2007 8:51 PM, Michael J. I. Jackson <mjijackson@gmail.com> wrote: > > On Nov 20, 2007, at 6:13 PM, David Coallier wrote: > > > 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. > > What I meant to say was that everything I've read and heard so far > indicates to me that PDO is the future of PHP database programming. > Sure it doesn't have as many downloads now, but there are plenty of > reasons for that: > > 1. It's newer > 2. MDB2 is easier to use and has more features > 3. There is more documentation for MDB2 > 4. PDO is distributed with PHP (I never downloaded it from PECL) Sure .. :P > > > 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. > > I understand what you're saying but just think about it...in order to > integrate support for the native PHP extensions and PDO...that's a > LOT of work! You would basically have two separate modes of operation > for database connections, and you would either writing twice the code > or putting little if statements all over the place checking if you're > supposed to be using PDO or the native extensions! ; ) It is a lot of work (Thus a community and not a one-man show) I'll try to explain at the bottom ;-) > > > 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. > > MDB2 won't be going anywhere...right? If people are so hooked on > using the native PHP extensions, even though they'll be slower, they > can still use that if they want to... > > > P.S. Oh yeah PDO is written in C ? Man that must be why it's so fast.. > > Sorry... Don't have to be, it was fun :) > > > - 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) > > The only thing PDORM_Domain_Inflector does is converts singular words > to plural. I guess I could create a separate package to do that and > then use it as a dependency, but I don't think anybody would use it. I know and that's the problem. You defenatly have to make it in a separate package and no people won't use it, but maybe some will, which is the important part. > > > - 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) > > Okay okay...changed. ; ) ;-) Thanks > > > - I cannot seem to see LOB handling and Iteration through resultset ? > > Is that on purpose ? > > PDO is supposed to be handling LOB...If not we can just port the MDB2 > implementation. > To be honest and being quite active in the php community, I have seen people swearing,crying,yelling and using the PDO lob handler. It works but you have to dig quite deeply into the documentation and "tests of your own". But hey, some people got it working the first time. I hate blobs anyways, just thinking ahead for the companies and people .. .still.. using blobs. > > - 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. > > I'm not sure I understand here. Make their own drivers? What are you > envisioning? Could you show me some pseudo code? Bah pseudo code is annoying let's just try to make a fake directory structure and a factory method here. Imagine class SuperORM File: SuperORM.php class SuperORM { /** * $name and $dsn would really only be $dsn and you handle * the name according to the dsn passed but that'll be simpler in * that example. */ public static function factory($name, $dsn) { $file = ucfirst($name) . '.php'; $class = 'SuperORM_Driver_' . ucfirst($name); // This of course would go in allfiles or autoload.... /** * This is a long way to say the file ./SuperORM/Driver/$name.php really.. */ require dirname(__FILE__) . DIRECTORY_SEPARATOR . __CLASS__ . DIRECTORY_SEPARATOR . 'Driver' . DIRECTORY_SEPARATOR $file; $new = $class::factory($dsn); return $new; } } // Here you have your simple class with a simple factory. File: SuperORM/Driver/Pdo.php class SuperORM_Driver_Pdo extends WhicheverWeNeedAbstract { public static function factory($dsn) { // Do all the PDO specific tasks and instantiation, etc etc. return new $pdoObject; // Whatever.. } } // Here you have your PDO driver File: SuperORM/Driver/Mysql.php class SuperORM_Driver_Mysql extends WhicheverWeNeedAbstract { public static function factory($dsn) { // Handle all the native infos here (Still using your own constants for attributes and random values) return new $mysqlObject; } } // Here you have your mysql specific driver What I am trying to show you is something I am sure you already know but just that you should not be using all the PDO::ATTR_* within the main class/factory because this will limit you to PDO only. If I look at your current code, the PDORM factory seems to be using a lot of PDO::ATTR_* which is setting barriers, keeping you within the distance of PDO only. Hmm, do you get what I mean ? Oh yeah, I understand that having a lot of native drivers is a lot of work, but subdividing into subpackages just like MDB2 is actually the way to go in order to "not have to work on ALL the parts :)" That's why there's a community, so people can work together and make powerful products. Also, I remember (too lazy to scroll up) that you said that MDB2 has more downloads because of documentation, this that, etc. Well I am personally recommending MDB2 instead of PDO in many companies now simply for that fact. I believe this is a very very VERY important factor of a winning open source project. Documentation, Press, Work, Community work, and quality. > > Thanks for all the suggestions and critiques. I really do appreciate > the time you've taken to look through it, and I'm taking notes of > suggestions. > Now this attitude is starting to please me :P > Michael > > -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18