Re: Re: one abstraction layer (my proposal for)

On Monday 03 December 2001 04:16, Manuel Lemos wrote: > Hello, > > "Tomas V.V.Cox" wrote: > > 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. This is a goal and not a requiriment for that stuff to work very good. Any way, from my point of view, only the core of this should be rewritten in C and shouldn't be too much code. Also I know that to write C code from an already existant php code is very fast. Have you ever see the speed that Stig or Rasmus (the two that wanted to do that) write C code?, it's amazing :-) > > 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. No problem here. This could be easily done fetching all the rows or even better altering the query (thing that Pear DB already does for ie. Oracle). > > 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. I'm not saying that all this goals has to be done in the abstraction layer. Some of them will be handled by external components. This point doesn't need to be acomplished for one to be able to start using the class. Making them as separate packages (that doesn't mean not highly integrated) opens the proyect to more people. > > 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. Same as in 4.13 > > * (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. I don't feel strong enough to talk about LOB support as I haven't ever used it. If someone else is wanting to do that would be very good. > > * (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? This point is part of the "ideas corner" section. I'm now in the process of studying the code and solutions adopted by both Metabase and ADODB in this area. Datatype abstraction and LOB support are the only missing things in PEAR DB. > >* 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. [snip] > The alternative for this is to use use conditional code, like > if(function_exists("whatever")) doit, else workaround it. Yes I'm aware and suffered it :-). Don't worry I guess that 95% of the code will work fine with any version > 4.0.4. Enough no? For the other 5% solutions like the one you proposed can be added. > > - 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. 80% usable in two-three months, means for me that the core functionalities will be avaible. Other stuff like caches, C, SQL parser, doc, etc. could be avaible soon only if people get involved. I'll write a more or less detailed plan if you think is necessary. But again this is not my proyect, is my proposal for a common proyect and that (or any other thing) won't get the success you and me want if the developers involved don't get enough support from people like you. Lukas, Joao and me as the proposed developers (if I'm not talking too fast) with the support and advices from you, John, Stig (if he finally gets his house sold :) and anyone willing to contribute, is a team strong enough to make this proposal a reallity in a little time, there isn't too much new code to write. The only thing we all need is to change our minds to be constructive, solve our differences and stop waste our time with anything than technical discussion. Tomas V.V.Cox