Re: one abstraction layer (my proposal for)

Hello, "Tomas V.V.Cox" wrote: > > I'm out of battles and want to explain my proposal for the idea of a new > abstraction layer that could benefit for all: My most relevant comment is that this proposal is not feasable any time soon. PHP needs an abstraction layer for the development of portable applications now, not in many months or years which is when this proposal would be accomplished with the features that are requested. The time that passes is not in favour of PHP. Despite what I wanted to believe, a lot of people is being moved to commercial platforms that have been catching up like the .NET platform using Microsoft products like ASP.NET. This will be more evident later but you can already see people with that mentality. One of the arguments is that PHP lacks of database portability and only works ok with MySQL. We know this is not accurate, but you know that most people is not so technically aware and can swallow arguments like this. A lot of consultants and sales people that want to defend concurrent products are using the argument of lack database independent API to defeat PHP. I am sure that some of you are aware of this. For those that are not aware, here is a precious pearl of difamation against PHP so you can see how much PHP has to loose because of this bad fame. Follow the links to see even more difamation even against Zend and other unrelated issues. http://babelfish.altavista.com/translate.dyn?lp=pt_en&doit=done&url=http://www.plugsys.com/brasil/products/msp20/tours/qa/qa04.msp Anyway, things like this are part of the reason why I proposed wrapping PEAR-DB around Metabase API. It would certainly be a solution that would be feasable and reliable in much less time than your proposal takes to accomplish. More on this below. Now for other comments... > Goals > ===== > 1) User selects mode: speed or portability (default) > > 2) Speed: > 2.1) Non critical features are included by demand > 2.2) There is public access to the database resources, letting people > the chance to interact directly with native calls when he want > 2.3) The more common database functions (connect, query and fetch) > will > be as lightweight as posible > 2.4) C rewrite when stable I would not put much hope on a C port because it really takes a very long time to accomplish. That is not a reason to not go for it, but also keep in mind that once you port it to C, it will several orders of magnitude slower and harder to maintain than a PHP version. > 3) Portability: > 3.1) All the features are avaible in all the backends (emulated when > posible and native is not avaible) > > 4) Features (in no special order) > 4.1) Unified and Extreamly Easy OO API > 4.2) Prepare/Execute > 4.3) Secuencial & Non Secuencial Row Fetching Metabase also has the possibility to return the number of rows before start fetching them from a result set, even with databases that do not have a function for that purpose. It is not very recommended for use with large result sets but some people just can't live without it. > 4.4) Quick data fetch (get*() methods) > 4.5) LOB support > 4.6) PEAR Error support and abstracted database error messages > 4.7) Information: about the database internals, the results, > the errors > 4.8) Datatype conversion functions > 4.9) Data quoting (manual & automatic) Quoting is done as part of datatype conversion. > 4.10) Limited queries > 4.11) Sequences > 4.12) Transactions > 4.13) Results cache You don't need to build this in the database abstraction layer. Result caching is just serialize the whole result set from an array to a cache container. Generic data caching components can do this like those that already exist in PEAR. These just need to be made concurrency safe, but that has nothing to do to what is being cached. So, you do not need to bother to put this in the database abstraction layer. > 4.14) SQL language builder/helper/parser (?) You'd better live without this. It takes a long time to do right and it is most likely not worth the effort. > 4.15) Database Manager (create/drop of databases, tables, sequences, > ...) > 4.16) Strong and deep test suite > 4.17) DocBook Manual, PHPDoc API, translations and annotated manual > 4.18) Easy distribution/installation with the Pear Installer > > Ideas Corner > ============ > > * Pear DB as the base code reviwed for the speed requirements and opened > to plug-in features on demand. > * (4.5) LOB support exchanged from Metabase This is going to be tricky. It is not a trivial job to detach this from the rest of Metabase. > * (4.8) Data Type conversion to be done by a more generic class > PEAR_DataType > (suitable to be used in other enviroments too, like xmlrpc, etc) Duh? What does data type conversion for each DBMS has to do with other environments? > * (4.13) Results cache to be done by the PEAR_Cache class > * (4.15) Exchanged from Metabase > * Development open to any experienced developer willing to contribute, > the > code will reside in the PHP CVS and the communication in php-db or > pear-dev. > * Developers from other abstraction layer packages are very very welcome > * The credits will go for all the people who has or is contributing > * No backwards compatibility fright. PHP 4.1 could be the first > supported I don't think this is a good idea. Maybe you are not aware, but a lot of people do not have any choice regarding the versions of PHP that they may use to run their scripts and Web applications. This is the case of people that have pages hosted in cheap or free hosting sites. Usually they have to put up with the PHP version that ISP decides to choose and almost never the ISP changes that PHP version on request of the user because that may break other clients applications. I have particular simpathy for PHP users with this constraints because they do not afford better hosting services, therefore they could not use a package that requires a higher version of PHP. The alternative for this is to use use conditional code, like if(function_exists("whatever")) doit, else workaround it. > version > * (4.16) A mix of: PHP tests/PHPUnit/Metabase Driver Conformance > * (4.17) All open > > Margin notes: > > - This is just my attempt to see the "DB_One" class done > - Maybe there is some part missing please say it > - Possible enhancements are welcome > - I, of course, make me volunteer Yes, it seems this is the relevant part for you. I think you misunderstood of my proposal and assumed that you were being excluded from participating on it. Actually that was not what was meant. People that are really willing to participate can always have a relevant role on what I proposed. > - I'll ignore flames or statement out of pure technical (please keep > them in > other thread or even better: privately) > - 80% usable in two-three months Based on what? I don't think this is a realistic estimate. It seems more like a wish, but I have no doubt that your proposal is not feasable in this little amount of time, even excluding the C port. This is really bad for the credibility for your proposal because people really want to believe it will be feasable in this little time but when the promised deadline arrives people will get back to you asking "where is the 80% usable that you promised?" ancd they will be disappointed. It is like that other guy you know who that promised not a very long time ago that PEAR-DB would be ported to C in 2 months! Which two months of which year, it was not mentioned! :-) I am not even saying that you will not be able to make it, but with a detailed plan that lists all the tasks and demonstrates what will be ready and when, you will not be able top convince anybody that you have a credible proposal. Just by evaluating the work behind the proposed items, I do not have any doubt to say that proposed deadline is pure wishful thinking, even more in a Open Source project where people are even paid to work on it nor have demonstrated that enough people can commit 100% of the time because most people have day jobs and other priority tasks occupying their personal lives. So, unless you can prove otherwise, please don't mislead people that really wanted to believe that your proposal is credible. 2 years ago there was a similar discussion about adopting Metabase that was just released after a 1 year of private development and Stig decided that he still wanted to do PEAR-DB by himself. Today we're having a similar discussion after realizing that PEAR-DB still does not offer true database portability among other stuff that Metabase could already provide then. I am afraid that in 2 years from now we will still be having this very same conversation because somebody behind PEAR decided to be stubborn enough just to do it his way instead of cooperating to adopt something that already exists, it is credible and reliable now! Then I will hate to tell you: "I told you it would be like that, wasn't it dumb to fight my proposal?" So, unless people open their eyes, PHP is doomed for being known as a language without support for developing portable database applications. I'm afraid there always be people that would like to disagree with me, but at least I am try to provide a feasable solution for that problem. Regards, Manuel Lemos