Re: general questions

Hello, "Tomas V.V.Cox" wrote: > > > Well, PEAR DB has all the features I need for my work. The rest of > > > > For now... I bet that in the beginning you did not need to have limited > > selects, but then you realized that you needed it and then you spent a > > lot of time working on something that Metabase already offered 2 years > > ago. > > Well, Metabase doesn't offer the stuff I'm trying to do for the Oracle > limit support. For the others drivers one haven't to work too much to > get it running. ALL Metabase drivers support limited select queries including Oracle. What you are talking about? As a matter of fact you ended up evolving to exactly the way it is done with Metabase, by specifying the limits in a separate call from the one that executes the query. Anyway, that was not my point. My point is that you say that PEAR DB has now all the features you want but it was not like that before you realized it needed things like the query limit support. Metabase already had that since almost the beginning 2 years ago. What I meant is that Metabase most likely already has now features that you will only realize you need them later. When you realize you need them you can already benefit from them without having to spend time and effort to implement them like the limit support. Limit support is one of the unique Metabase features that have been borrowed by PEAR-DB. I think it is silly to play catch with Metabase and do it yourself in PEAR-DB when you could benefit from these features if you accepted my proposal. > > What other Metabase features will you realize that you need in the > > future? Couldn't just you be denying that you may need the Metabase > > features just to not admit that this "merge" is not a good thing even > > for you? > > My god, when I ever said that? I was only talking about my personal > experience with PEAR. It was a pertinent question. It is what suggests when I see so much reluctance to accept a proposal that a lot of reasonable people have agreed to. > > > things are not of my personal interest and my only interest on them is > > > > So, because it is not of your interest, it could not be of the interest > > of anybody else? Is that what you are saying? > > Bah Manuel, don't try put my words out of context. The 80% of the things I am not. It was a question. > I have contributed to PEAR are not of my _personal_ interest. I spent 2 > days with the Oracle limit support, install a Oracle at home, break my > head in that and try to make it work, for what if I'm not using Oracle > nowadays? The same applies for a bounch of other things like the > DB_FETCHMODE_OBJECT (I don't use it as it's more confortable for me the > ASSOC) or the tutorial (I do know already how to use PEAR DB) for > putting some quick examples. It is that it seems that you are not interested that somebody adds abilities that you are not interested in. > > > only because this is a Open Source proyect and I get fun developing for > > > it (or it isn't the reason why we are here?). > > > > Fun? Have you been reading too many Linus books lately? :-) > > No, but for sure I would have to :) > > > I think if there is going to be any funny, it will be a consequence not > > a goal. I think it is more important to have vision that will let us > > work on something that is beneficial in the long term. Just for fun of > > doing it was what it seems that made PEAR developers start their own > > database abstraction package 2 years ago. After all this time, PEAR-DB > > does not offer database portability and many other features that > > Metabase offered already when PEAR-DB was started. It might have been > > fun for you, but that was not such a great progress because PEAR-DB > > still lags feature wise. > > Just for fun or not PEAR DB had have quite success. Just for fun or not > many Open Source proyects are beating propietary software in many areas. There is no proprietary software envolved here, so that is irrelevant. > And for your eternal statement about the "features", yes we all agree. > But if there is no other abstraction layer that do some of the unique > things of Metabase is because all others failed to implement them or > perhaps they consider that aren't really so necesary? Are you saying that an abstraction package that provides full portability is not so necessary? Could Sun be so crazy that developed Java and JDBC for any reason that portability is a necessary thing to save development costs among other things? Honestly, I don't see other reason for you to object against Metabase! > > > IMO the need for a "merge" has nothing to do with software, I see it > > > like the chance of joining developers to get more minds to build greater > > > > It's not just that. With only one database abstraction layer, you get to > > reuse each other components that have been developed independently but > > for the same API. You do not have to join people. > > First we join, then we develop, isn't the objective of a "union" to > build one database abstraction layer? What I mean is that other people can develop tools and components based on an abstraction layer without ever joining to the development of the abstraction layer itself. > > > things. Noone is willing to rewrite anything. I previously said it, the > > > way IMHO this could get some success is writing a spec that "all" the > > > people agrees and then cut & paste the best pieces of code from each > > > abstraction layer. > > > > Keeping different database abstraction packages is what we already have, > > so what you suggest does not represent any progress. > > > > > > So I must say my starting point will not be PEAR! I have no problem with > > > > the PEAR the function names that PEAR uses .. so I do not see a reason > > > > why not to use the same functions for the final version using those > > > > names (and therefore not requiring a wrapper to make use of those > > > > names). > > > > > > Anyway, is it just my impression or you seem to be using that just as an > > excuse for boycotting my database abstraction merger proposal? > > Nop. I'm all open of a team merge and to build the ultimate abstraction > layer. But if you are trying to do that by your self, with your own I made a proposal to use software that is ready now (not in two more years) and have given undeniable proof of reliability, it is throughly documented and provides unique features that are highly desirable. The fact that I developed it has nothing to do with the proposal. The fact is that PHP needs one and only one proper database abstraction package. It is you that convinced yourself that my proposal only has to do with the fact that I did it. > rules, your software, etc. probably I won't contribute to it. But that's You only not be able to contribute it if you exclude yourself. It is up to you. > only me, you don't have to worry about me. I'm only buzzing here trying > to ensure that this is really open to others. > By the way, please tell me what exactly you mean with "my database > abstraction merger proposal", the "Adoption of Metabase"? I made proposal to merge database abstraction package. Because I made the proposal, it is my database abstraction proposal. The proposal is about the Adoption of Metabase to provide the functionality with PEAR-DB interface. That's all it is about. What is the difficulty to understand this? > > You should know by now that Metabase offers many outstanding features > > that others don't (if not, you had plenty of time to go and learn about > > it), so why this objection? > > > > > to simplify the PEAR architecture to make it more lightweight/fast > > > without loosing its great usability. And that's me, others will have > > > better ideas. > > > > > > What you are wanting to do is to rename Metabase functions to be more > > > similar to PEAR DB? It's the same statement you said before: Stig's code > > > is not crap! Why not just do a better API for Metabase and forget the > > > merge? ;) > > > > Duh? That's what I proposed, wrap Metabase API around a PEAR-DB driver. > > > > > __IMHO__ if you want (I also want) to get succes don't came here in 4 > > > days saying: "Here I present you the new API of Metabase, take it and > > > use it". And I repeat, this is my only opinion. > > > > That is what Lukas is doing, but first he needs to learn about PEAR API > > to figure how one thing can fit in the other. > > Umm ... perhaps my limited english is confusing me, but I though that > Lukas agreeded with me about starting this stuff from a more common > point instead of directly use the stuff you think is better (what was > about the bad that the "ego" is?). Lukas wanted Metabase to have a "more OOP like" interface for Metabase. I made the proposal for having only one database abstraction package. So, if Lukas can wrap Metabase API around a PEAR-DB API, both things can be achieved leting PEAR-DB users benefit of Metabase features. > > > > I will not port some of the stuff that is part of the PEAR DB fetch*() > > > > stuff. Those features basically allow a programmer to write bad SQL > > > > queries and then do the real sorting/searching inside of PHP. But anyone > > > > else is obviously welcome to do this. > > > > > > Huh? I you don't port fetch* you won't be able to retrieve rows :) You > > > are refering to other thing no? > > > > Not, Metabase does not need cursor positioning functions, because it > > lets you specify row numbers in the data fetching calls. If those will > > be implemented is just to emulate the sequential interface of PEAR-DB. > > PEAR DB supports fetching rows by number, I implemented that for the > Pager long time ago. So, why more than way to do the same thing? > We can end old discussing and discussing, and all can be just resolved > if you clearly write somewhere your idea/goals, who is involved on it > and how you plan to implement it. With that no more discussion posible, > if people likes the idea will help and the ones who think other thing > will continue their lifes. Duh? That is what I did in my initial proposal message! Regards, Manuel Lemos