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

Hello, "Tomas V.V.Cox" wrote: > > 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. Yes, I just meant to not put much hope that it will happen real soon. > 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 :-) Tomas, please be realistic because you are making people believe that it is feasible any time soon. Nobody is doubting of the capabilities of Rasmus, Stig or whoever will code it in C. The issue is that the amount of PHP code is large, converting and debugging it will definitively take an etternity. > > > 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). hummm... I don't know if you got it right. The question is not changing the amount of rows returned by a result set, but rather returning the number of rows in a result set without retrieving the rows from the application point of view. Metabase does that by storing any rows that remain to be fetched in an internal buffer of rows, but for the application it will continue to be as if you did not fetch those rows yet. This is tricky because among other things it will interfere will an eventual emulation of limited selects. What I mean, is that this may require a lot of code to be done right within each driver. > > > 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. What I am saying is that you do not need anything in the database abstraction package because there is nothing that it needs to do to support this except for providing a way to return the whole result set in 2 dimensional array which is a useful feature that has nothing to do with caching. > > > * (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. Trust me, it is tricky. Even though you can provide a portable API for this you should be aware of many details that may discourage you from using LOBs in some databases, like MySQL or MS SQL server. Just read Metabase manual on database specific issues to have an idea. > > > * (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. Ok. After you study Metabase, if you do not understand why something is in some way, please ask me. Don't just act like John Lim that looked at Metabase code started criticizing without fully understanding it. > > >* 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. Yes, keep in mind that some PHP 4 versions had some silly bugs that ended up propagating to Metabase, like the infamous problem of result set handle resources being converted to strings instead of being treated as integers as they are. There are also still remaining bugs with ODBC with no perspective of when they will be fixed. > > > - 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. But based on what? > 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. That is the problem. First you did not elaborate a plan detailing the tasks and estimating the time they will take. Second you don't know if you can count on other people's help. What credibility does your estimate have? None. The problem is that the way you put that estimate people are taking it for granted because they really want to believe it is feasable and will be done. > 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. There would not be much new code to write if just be interfacing PEAR-DB API with Metabase. Since you insist on rewriting Metabase code to insert it in the current PEAR-DB classes, you will have plenty of code to write. If you want to believe otherwise, you will be fouling yourself and whoever wants to believe in that. If you really want to drag Metabase code inside PEAR-DB, why don't you just build a test like Stig called it with PEAR-DB around Metabase just to demonstrate it will work and then if you think it is feasable drag Metabase code inside the current PEAR-DB classes? > 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. Right, I am try to be technical since the beginning. The problem is that some people are assuming that this a personal quest of Manuel Lemos and we end up spending a lot of precious time answering to personal attacks and accusations that I am doing this just for personal interest. People ought to know me better before bothering to hit me. Regards, Manuel Lemos