Ulf Wendel wrote: > Hi! > > Drizzle aims at the web market but it lacks support for (server-side) > Prepared Statements. How does that work out given the constant move > among the userbase towards Prepared Statements. > > PHP is one of the major players in the web market. Together with PHP 5 a > database access abstraction layer called PDO has been introduced. PDO > and the MySQL driver for PDO (PDO_MYSQL) focus on Prepared Statements: > everything is run as a Prepared Statement. Over the years PDO_MYSQL has > becomes more popular although it suffers both from the status of > Prepared Statements in MySQL and the PDO overall design. Something > similar goes for Connector/J and JDBC. They also focus on Prepared > Statements. > > JDBC works around it with a pretty solid client-side Prepared Statement > emulation. PDO_MYSQL can't work around it as it suffers from the stinky > PDO client-side emulation. And ext/mysqli, the PHP flagship extension > and reference implementation is entirely lost as it has no client-side > emulation to offer at all.
This is the real problem as I see it. > To make a long story short: expect PHP users to bail out badly. Bail out > on the same topic like in the years before - MySQL has no proper > Prepared Statements solution. ] > Brian tried to kick off some brainstorming on PS in his blog [1]. Both > he and Lukas Smith [2], as of shortly a [Co-]Release Manager of the PHP > 5.3 series, have blogged about PS before I found time to raise my voice > on PDO and PS [3]. Its been a rather vivid blog discussion. > > Things I remember from the discussion: > > - current PS implementation of the server does not scale well And never will. > - todays developers are lazy and maybe less skilled: > they rely on garbage collections and keep handles open > for ages - the server > > - the server does not do much more than cache the parse tree: > parsing can make 25% of the run-time of a short query Well, the parsing problem is actually a whole other conversation I'm trying to have... (in short, I want to push parsing to the client library and have the ability to send the parse-tree over the wire) > - PHP users love "secure" binding Yes. But can be done just as well in the client as in the server. > - binary protocol can mean significantly less conversions > - binary protocol can mean less traffic > > What is the Drizzle roadmap on Prepared Statements given that PHP, a > major player in the web market, will not play nicely with Drizzle > without a vision implemented by Drizzle and MySQL Connector team folks? If you want to scale in a massive web scale out environment, Server-Side prepared statements are a terrible idea. Full stop. Same thing with Stored Procedures. People think they want them, because they are the way things are done in Oracle, so they must be "right". (Conventional wisdom takes a while to die - just like bad slashdot rumours) But they aren't really considering that they are offloading work _from_ the most easily scalable piece to the the most difficult piece to scale. Scaling is all about pushing more and more pieces towards the edge... Perl, Java and Python all have good client-side PS emulation, and have had for years. I was using DBD::mysql "prepared statements" with MySQL 3.23. Whether the server-side has PS or not or they are any good or not, I can't believe PHP can't provide a good emulation layer for their users (I've seen some pretty fantastic driver code out of you guys...) for the general web case, which is that SSPS are actually a bad idea. Of course, that API layer could also, like the other languages, be configured to use SSPS if the user chooses... Just my $0.02 of course. Monty _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
