Re:Drupal Sucks
by gaius on Sunday October 04, 2009 @12:16PM
(#860236)
Or perhaps not using MySQL. Table locks indeed, this is 2009!
[ Parent
| on HN ]
Meh, it's not so much MySQL that's lame in this case, it's just the MyISAM engine, which depressingly enough is still common in 2009. MyISAM is based on IBM mainframe database technology developed back in the stone age. The InnoDB engine doesn't have these kinds of locking issues.
Getting Drupal to run on a non-MySQL database is non-trivial. Here's an interesting article detailing what folks at Oracle had to do to get it to run on Oracle.
http://www.oracle.com/technology/pub/articles/pedros-drupal....
The article was written about an effort using Drupal 4 ... and it turned out to be suprisingly easy due to the structured nature of the Drupal database api. Did you read the stuff??
I stand behind my use of the phrase "non-trivial". The fact that Drupal has a reasonably clean DB communication layer that separates out bind variables to avoid injection attacks was why they didn't give up on the project at the start. I doubt anyone involved in the project would describe the effort as "surprisingly easy".
Unfortunately, while drupal ostensibly supports other database backends, the reality is that it doesn't support other database backends.
Re:Drupal Sucks
by CitizenKane on Sunday October 04, 2009 @01:39PM
(#860351)
This is something that is being rectified with the upcoming Drupal 7. This is a rather tough nut to crack because different database servers don't actually have compatible SQL syntax even among some basic queries. A lot has been done to improve this, including an API to declare database tables in a way which is SQL server neutral. And Drupal 7 will also have query builders to deal with differences in syntax among some of the more basic queries.
It's not even a matter of SQL syntax. Oracle, for example, uses cursors implicitly and declaring a cursor just gives you a handle to it. In SQL Server, using a cursor is an expensive operation. So if you are trying to be database-neutral, do you use cursors or not? How does that affect the likelihood of deadlocking? Etc etc etc.
In practice if you try to be database agnostic you end up with something like SAP which runs like molasses in Winter equally on all databases...
The problem is not enough abstraction. If your application code sees things like cursors or SQL statements, your design is broken.
I'm talking about inside Drupal itself. Locking strategy is another one: it's impossible to optimize for one database without sucking on another. Lots of developers with experience only on one don't even know they're doing it, they think this is just how databases work.
Being database agnostic makes as much sense as trying to write code that compiles in both C and Java.
Being database agnostic makes as much sense as trying to write code that compiles in both C and Java.
Maybe if you are writing the realtime transaction processing system for Visa... but this is a CMS. Flexibility is more important than absolute speed. 99% of page views are going to be served from the cache.
The percentage of page views served from cache depends on the type of site you're building. Newspaper site? Sure, cache it all. Social network? It's going to be tough to manage a cache when the content is constantly changing and is viewed differently by each user.
Re:Drupal Sucks
by brandnewlow on Sunday October 04, 2009 @02:05PM
(#860397)
This all sounds like a nightmare for the casual/less-proficient developer to figure out. Is this a problem that a majority of Drupal developers face?