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

Manuel Lemos wrote: > > Hello, > > "Tomas V.V.Cox" wrote: > > > > > > 4.3) Secuencial & Non Secuencial Row Fetching > > > > > > > > > > > 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 > > That is a problem because Metabase has features because users need them. > If PEAR-DB will not have those features you will discourage people to > migrate from Metabase. > > > 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"; > > This is not the same thing. People often what to retrieve the number of > rows to display, and only after that they want to display the rows. The use of templates is common practise, also the PEAR DB numrows emulation by altering the query works quite well in most of cases and don't force the user to retrieve all the rows if he don't want to do it. > The > way you do it you make people buffer the rows to be able to display the > count before their contents. People appreciate this in Metabase because > they don't have to fetch and buffer all rows as Metabase does it for > them if necessary. Besides, some database like MySQL already buffer the > result set rows, so your solution wastes at least twice as much memory. Apart from the fact that MySQL do natively support numrows, it's funny you say that PEAR DB consumes twice much memory when Metabase do store ALL the data in memory and could crash the app if the number of rows is big. For those how want to retrieve all the data we have: $data = $db->getAll(); $numrows = count($data); No tricky code in the lib. And they will know in all the moment that they are storing all the data in memory. > > 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. > > Just as you did include features on request in PEAR-DB, you should be > consistent and include features that people already use and appreciate > in Metabase in order to motivate them to migrate. > > > > 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()? > > So, there you do not need anything else to cache results. I just don't understand you here. getAll() will cache what data? I was refering to a system that completely manage the cache or even the enhanced John's idea of "disconnected recordsets". > > > > 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 > > Don't care about being credible? Yes I care. And what I'm doing is compromissing my self. That's the difference with my position and yours. > > 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. > > You are avoiding the issues. In 3 months people will charge you for what > you promised and what you will tell them then? You will loose your > credibility and next time your arguments will not be taken seriously. > > I hate when imature people start making great promises of wonderful > developments and in the end they give up or otherwise end up not > developing even a small part of what was promised in the time that is > mentioned. That is extremely irresponsible and unprofessional. lol. And you talk then about boycotts? Unbeliveble :-). If you are a so a claivoyant please tell me where Osama bin Laden is. > > > 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 > > Of course it will. A wrapper will let you figure exactly what new > functions you need to add to PEAR-DB API to provide Metabase features > without having to implement them now. I know what things are missing in PEAR: data type conversion and LOBs. Three months for that takes time to any developer to learn PHP and copy and paste that features even reading all your posts. > Meanwhile you will be able to > provide functional version much sooner than the long time that it will > take to implement your proposal. But my proposal is the thing that people is expecting from a proyect called: "one abstraction layer" and not the one called "adoption of metabase". > > 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. > > ADO-DB does not provide half the features that are need to achieve the > level of portability that Metabase provides. > > John Lim is only willing to develop the PEAR-DB wrapper class for ADO to > motivate PEAR-DB users to drop it and migrate to ADO-DB. Once the users > start using ADO-DB specifics there is no way back for them. This a trap > that they may fall. > > On the contrary, what I am proposing is to provide to the official > PEAR-DB API function calls that provide the features that Metabase has > to motivate Metabase users to migrate to PEAR-DB as my goal is to have > only one database abstraction. To put PEAR DB over something or to put something over PEAR DB sounds the same for me. The point is to take advantage of all the best code of them, join our minds and mix it under the umbrella of the PEAR API that all agree is the more comfortable. > > (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! > > There is no point on doing that. You would only change Metabase code if > you insist on doing that. There is always that rule of thumb that you > should not fix what is broken. As for long names, you can interface > directly with Metabase driver class methods so you will not need to even > type the Metabase prefix. > Perhaps not as user but indeed as developer. With clean and easy code to read we increase the chance of getting patches and contributions. I just don't know why I'm still here discussing with you. I'm only wanting to be constructive and your statements are only destructive. Tomas V.V.Cox