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

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 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 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. > 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. > > > 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? > 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. > > 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. Meanwhile you will be able to provide functional version much sooner than the long time that it will take to implement your proposal. > 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. > (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. Regards, Manuel Lemos