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

Manuel Lemos wrote: > > Hello, > > "Tomas V.V.Cox" wrote: > > > > > > > 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. I know you do the kind of things I don't want to do :-). With the PEAR DB API there is no need to that kind of things to get the number of rows. See: $numrows = 0; while($row = $dbh->fetchRow()) { $numrows++; //rest of code } if (!$numrows) { $numrows = 'no'; } print "There were $numrows results"; I'm not sure if we should introduce things that could flood the resources if aren't used with really care (at least knowing how many rows a table has). Anyway if the people agrees with that a door will be opened for it in the compatibility layer. > > > > 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. getAll()? > > > > * (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. Ok. > > 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. You are building a mountain from that. Just don't care. I made my estimations of the needed work (do you remember who wrote the proposal?) and the time I want to put here. Much more than simply saying that this should be made that way but I just don't have time. > 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? Because a wrapper will demostrate nothing. ADODB already has a PEAR DB API compatible wrapper very nice, so what do we do then? We should do directly the native class, don't waste our time with wrappers. (In the other hand I would spend the rest of my life trying to adapt the code to a uniform coding standars and to short the ultraExtraVeryLongVariableAndMethodNames that I personally find uncomfortable to read and write code.) <- That's not the reason! > 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. Just ignore them. Tomas V.V.Cox