Re: general questions

Hello, "Tomas V.V.Cox" wrote: > > Also as Manuel pointed out Metabase is OO .. so porting is not that > > insanely difficult todo. Like I said we had some thing along the lines > > of the get*() PEAR DB functions in metabase in no time at all. > > > > Also Manuels code is not crap! And I do not see any point in redoing all > > of his work. If you want that then there is nobody stopping you from > > writing all of Manuels features into Pear DB and then there is no need > > for a "merge". > > 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. 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? > 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? > 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? :-) 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. > There is a lot of code to read, but before starting to read all the code > of all the PHP abstraction layers I prefer to take a look at solutions > more wide/wise/tested like DBI. I think you need to read the limitation section of DBI manual and also Metabase manual before you judge. Anyway, if you want to really look at a good abstraction layer, look at JDBC. It represents a sort of consensus in the database industry because all the major database vendors have been envolved to make sure that it supported properly their database features. > 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. > 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). > > But Metabase is slow, why select it as the core? I have many ideas how Slow? Says who? Ah, John Lim who happens to be ADO-DB author and that sells a database tool that is based on ADO-DB. Anyway, is it just my impression or you seem to be using that just as an excuse for boycotting my database abstraction merger proposal? 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. > > 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. Regards, Manuel Lemos