Re: [development] Do not let postgresql hold back great patches
On Mon, 12 Nov 2007 08:29:34 -0500, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Amen brother. I am happy which simply removes LOWER from those queries and kicks the ball to the postgresql half of the playground. As I stated on my blog I have nothing against posgresql just I do not want to deal / held back with it. Any support for this solution?
IMO, we need to focus on Drupal SQL[1] and not MySql SQL or Postgresql SQL or Oracle SQL for coding purposes. Another layer of abstraction handles the nitty gritty of each different DB. AFAIR, the code prior to 6 was both MySql and PgSql friendly. So making a change in a different direction for Drupal 6 doesn't seem TRT to me. However if Drupal 5 wasn't as PgSql friendly as I remember then I agree with Karoly. For Drupal 7 I would like to see Drupal SQL handle all of the syntax changes needed for various DB engines; that means no more testing of $db_type outside of the Drupal SQL abstraction. Then a company with Oracle, Sybase and DB2 could display data from all three database types comfortably with Drupal.
You have just proposed that we create our own serialized language called DSQL that we then regex for *every single query* and then rewrite a query for each database backend according to some abstract set of rules. No. That is way too complex and way too slow, especially when it would involve slowing down MySQL (95%) users purely for the sake of everyone else (5% at most). It is also a sign that the architecture is bad: If you serialize a data structure and then string-parse the serialized version, you are doing something wrong. You should have parsed it first, then serialized. The only alternative I see is to use data-structure-based query builders instead in some cases. We do that now for DDL statements (Schema API). I'm planning to do that for all insert/update/delete statements in Drupal 7, and I'm pondering how feasible it would be to require certain types of SELECT queries to use one. I'm still undecided. That is, however, beside the point for right now. Right now, the point is that we're holding back a performance improvement under MySQL and a way to increase the number of shared hosts Drupal runs on (those that don't allow temp tables) for the sake of PostgreSQL, which few shared hosts support anyway. While I agree that forcing us to think about multiple databases is good architecturally, we just don't have the resources to support non-MySQL as well as we do PostgreSQL. I would not object to committing the MySQL portions and fixing PostgreSQL later. --Larry Garfield
<devils-advocate> A smattering of thoughts: 1. Nice Catch-22 or Chicken-and-Egg situation we have here. It's sort of like the push for PHP5, only that kind of effort is more the Postgres community camp. 2. Not many Drupal sites use Postgres, so why support them? Maybe there would be more, if we supported Postgres. 3. About the time MySQL reaches version 6, it will have roughly a comparable feature set to Postgres 7 (more than 3 years old, now). 4. For every feature we use that is easier or better in MySQL than in Postgres, there are items that are easier or better in Postgres. We just haven't taken advantage of them. 5. Not wanting to abstract the differences away between databases is partially built upon the conceit that all Drupal developers are good SQL developers as well. In reality, the vast majority of us should never write a line of SQL; instead we should be asking a Drupal API to fetch/replace an object for us. In practicality, that will never happen, as it has adverse effects outside the quality of code (e.g. the volume of code, novel new applications, etc.). 6. Regarding previous remarks about the slippery slope and chx's demand for some evidence: you should know better, chx. The evidence is simple and obvious: if we code specifically for one database (one browser, one screen size, one RSS reader, one whatever), the effort to then open up and use others at a later date is much larger than if we always coded with that thought in mind. My stomach hurts; I'm feeling grumpy. </devils-advocate> Wasn't there once an effort to provide an sqlite version of Drupal? :-)
On Nov 12, 2007, at 11:46 AM, Chris Johnson wrote:
2. Not many Drupal sites use Postgres, so why support them? Maybe there would be more, if we supported Postgres.
Once all of the modules I use support PostgreSQL, I intend to switch over. It bugs me having to run both databases, and everything else we do uses PostgreSQL (or Oracle, but that's not on my servers...).
Wasn't there once an effort to provide an sqlite version of Drupal? :-)
And could this be brought back? It would make setting up a home development version much easier, as I don't really like having to install a complete database server on my home machine. Ricky The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information.
On Mon, 12 Nov 2007 12:23:37 -0500 Richard Morse <remorse@partners.org> wrote:
On Nov 12, 2007, at 11:46 AM, Chris Johnson wrote:
2. Not many Drupal sites use Postgres, so why support them? Maybe there would be more, if we supported Postgres.
Once all of the modules I use support PostgreSQL, I intend to switch over. It bugs me having to run both databases, and everything else we do uses PostgreSQL (or Oracle, but that's not on my servers...).
In my experience modules needs very minor tweaks to run under pgsql. Furthermore most modules are simpler and smaller than core... I know that if one upgrade break up something most of the time it will require 5 minutes to fix pgsql compatibility back. I wouldn't dare with core. Again a Chicken-and-Egg situation. If it would be easier to implement modules that support both DB... One way is actually provide an api that hides the DB... another is suggesting a standard guideline to support different db in modules. For the reasons expressed I'd feel as a big loss if drupal will support one DB only... even if by a miracle it would be pgsql. BTW as someone pointed out if drupal would be designed with pgsql in mind first... mysql would seem dumb and missing features etc... -- Ivan Sergio Borgonovo http://www.webthatworks.it
Quoting Larry Garfield <larry@garfieldtech.com>:
You have just proposed that we create our own serialized language called DSQL that we then regex for *every single query* and then rewrite a query for each database backend according to some abstract set of rules.
No, that isn't what I proposed exactly. It is what you read into it. The query need not be rewritten if the structure is sane to begin with. If precious MySQL is the favored one, we say Drupal SQL uses its syntax structure. Everything else then is slightly slower because the string needs parsed to syntax manipulate the string. And if done correctly the parsed string is cached so that it doesn't have to reparsed. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Op maandag 12 november 2007, schreef Larry Garfield:
The only alternative I see is to use data-structure-based query builders instead in some cases.
While I agree that forcing us to think about multiple databases is good architecturally, we just don't have the resources to support non-MySQL as well as we do PostgreSQL. I would not object to committing the MySQL portions and fixing PostgreSQL later.
This whole thread is the main reason why many projects choose to build a really DB independent system. Like AdoDB or Active Record. Those two, IMO are OTT for drupal, but still, its worth noting it down somewhere: "Nov 2007: big issues, long threads, frustrated developers, delayed release: caused by our DB-bstraction, not being really abstract enough". Bèr -- Drupal, Ruby on Rails and Joomla! development http://webschuur.com
participants (6)
-
Bèr Kessels -
Chris Johnson -
Earnie Boyd -
Ivan Sergio Borgonovo -
Larry Garfield -
Richard Morse