SitePoint Sponsor |
|
User Tag List
Results 26 to 47 of 47
Thread: Is PDO the new standard?
-
Oct 9, 2008, 12:21 #26
- Join Date
- May 2006
- Location
- Lancaster University, UK
- Posts
- 7,062
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Well, if you're used to an object returning database results, you'd want it FETCH_OBJECT.
If you're used to using mysql_fetch_array, you'd want FETCH_ASSOC or FETCH_ARRAY, depending on your goal.
For those used to grabbing everything from the db, they want FETCH_LAZY to make things faster.
There are more. Alot more.
But each are suited to a different situation.
A car company is going to be useless if they only sell cars suited for people under 4ft high.Jake Arkinstall
"Sometimes you don't need to reinvent the wheel;
Sometimes its enough to make that wheel more rounded"-Molona
-
Oct 9, 2008, 13:05 #27
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I have to agree with McGruff on the FETCH constants. It feels needlessly complicated, and there is nothing that prevents users to implement specific solutions atop the API. Apart from that, using constants as arguments is just bad style.
-
Oct 9, 2008, 13:21 #28
- Join Date
- Sep 2003
- Location
- Wixom, Michigan
- Posts
- 591
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I am no big fan of long lists of constants either. But I think dismissing the entire PDO library because of that design flaw alone is a big stretch. Specially considering the alternative which we come from; the hodge-podge of DB specific functions.
Do you also recommend against using PDO entirely and going back to the stone age of database access functions we had before?
How would you better handle the 70+ different configuration options? So long as we don't have a better idea, it is not much use to complain, is it?Garcia
-
Oct 9, 2008, 22:29 #29
-
Oct 10, 2008, 01:34 #30
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
-
Oct 10, 2008, 07:08 #31
- Join Date
- Nov 2003
- Location
- Huntsville AL
- Posts
- 706
- Mentioned
- 4 Post(s)
- Tagged
- 1 Thread(s)
-
Oct 10, 2008, 07:56 #32
- Join Date
- Sep 2003
- Location
- Glasgow
- Posts
- 1,690
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
The constants could be tamed with, in order of preference:
(1) First, and most important, identify all the useless options and dump them. The problem immediately becomes much, much simpler. If anyone desperately needs some obscure configuration option they can extend the standard, off-the-shelf class.
(2) Create new types. Eg PDO::ATTR_PERSISTENT might suggest a new PersistentConnection class. Bang goes another constant.
(3) Do the config at instantiation ie set up once wherever you create the object graph and keep the actual app as simple as possible.
(4) As mentioned above, add new methods.working on: Aperiplus, Rephactor, Phemto
useful links: xUnit test patterns, martinfowler.com, c2 wiki
-
Oct 10, 2008, 12:47 #33
- Join Date
- May 2006
- Location
- Lancaster University, UK
- Posts
- 7,062
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
The simplest way of going round this is to set a default fetch type when instantiating the PDO object. Sure, there's a long list of constants to choose from - but when you're only going to type it once in your application, complaining about it is... it's just petty.
Jake Arkinstall
"Sometimes you don't need to reinvent the wheel;
Sometimes its enough to make that wheel more rounded"-Molona
-
Oct 10, 2008, 14:41 #34
- Join Date
- Sep 2003
- Location
- Wixom, Michigan
- Posts
- 591
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I like it. The only thing I would add is that there are so many constants (I think over 70!) that some of these groups of constants might fit into one pattern and some may fit into another.
For an instance, the prepared statement bound parameter constants might be best dealt with by new methods (bindInt, bindString, etc...)
Some, like you mentioned, need to be thrown away entirely; such as the ability to choose the method of error reporting. IMHO it should just be Exceptions and exceptions only, if you really want your errors to show up as traditional PHP errors it is simple enough to wrap your methods in a catch() block.Garcia
-
Oct 10, 2008, 15:15 #35
- Join Date
- Apr 2007
- Posts
- 1,205
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
There's a simple way to do this. Years ago before PDO was introduced, I tried an ADO script in PHP (might have been phpADO) and found its configuration options unnecessarily complicated. So I wrote a very simple script that was similar to it but only had the features I needed.
What I did was have the query() method return a simple Recordset object regardless of the query type. In addition to a hash containing a rowset for SELECT queries, the object had lastInsertId, affectedRows, and other properties which I've forgotten. Depending on the query type, each property would be either null or an appropriate value for that query.
-
Dec 7, 2008, 13:58 #36
- Join Date
- Aug 2005
- Location
- Winnipeg
- Posts
- 498
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I was refered to this thread from Devnetwork after I posted some code I hammered out yesterday.
Basically I have experienced the same problems as mentioned in here with PDO...I personally found the interface a mess and quite confusing and overly complex, so in attempt to simplify it I wrote this wrapper library.
http://code.google.com/p/pdowrapper/
One of the most challeneging aspects has been on how to handle the setAttribute() problem.
Initially I tried to figure out if it was possible to organize each setting with an associated object and thus call a explict member function as opposed to passing a constant which might not even apply to the selected driver, etc...
This has proven difficult as I am not overly familiar with many other RDBMS.
I wanted to somehow associate a setBufferedQueries method to only the MySQL connection object() but without introducing dependencies to the conneciton object (mainly the PDOStatement or connection object) it's difficult to set the attribute.
I would really appreciate some feedback in this regard.
Cheers,
AlexThe only constant in software is change itself
-
Dec 7, 2008, 19:17 #37
- Join Date
- May 2007
- Location
- Poole, UK
- Posts
- 5,077
- Mentioned
- 103 Post(s)
- Tagged
- 0 Thread(s)
imho it is better to use the mysql_* over PDO as:
- Speed: PDO is slower then mysql_*. It might not make much difference for small to medium sized apps but once an app gets big enough the difference in speed will be noticed.
- Security: PDO may have an advantage over mysql_* with the use of prepared statements but I feel that any values for use in a query should be escaped and validated before being added to a query.
- Standardization: Each database has it's own variations of SQL, until all databases use exactly the same SQL command set, in exactly the same way.
- Baggage: To handle the various databases PDO must have the code for communicationg with them but if you know that you will only ever use MySQL then a lot of the code in "baggage" as far as your app is concerend as it would only need the code for accessing MySQL.
Community Team Advisor
Forum Guidelines: Posting FAQ Signatures FAQ Self Promotion FAQ
Help the Mods: What's Fluff? Report Fluff/Spam to a Moderator
-
Dec 8, 2008, 01:44 #38
- Join Date
- Aug 2005
- Location
- Winnipeg
- Posts
- 498
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Speed: PDO is slower then mysql_*. It might not make much difference for small to medium sized apps but once an app gets big enough the difference in speed will be noticed.
PDO may have an advantage over mysql_* with the use of prepared statements but I feel that any values for use in a query should be escaped and validated before being added to a query.
PDO handles escaping for you...
Each database has it's own variations of SQL, until all databases use exactly the same SQL command set, in exactly the same way
To handle the various databases PDO must have the code for communicationg with them but if you know that you will only ever use MySQL then a lot of the code in "baggage" as far as your app is concerend as it would only need the code for accessing MySQL
Cheers,
AlexThe only constant in software is change itself
-
Dec 8, 2008, 13:52 #39
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I feel that I have to correct you on these points, SpacePhoenix.
Firstly, it's a good idea to put the responsibility of escaping strings as close to the consumer of it as possible. Magic quotes is an example of what goes wrong, when you don't. Or you get sql-injection vulnerabilities.
Secondly, bound parameters are actually safer than embedding values by escaping them. That is because with bound parameters, the query and the data are transmitted separately, so they are never mixed, and thus no injection can ever get through.
Is it? I have used PDO with some pretty big applications, and I didn't notice any bottle neck there. What do you base your assumptions on?
PDO is not a database abstraction layer. It's a database connectivity layer.
PDO is split up into multiple extensions; The main extension, and one for each database driver. If you only use MySql, then just install pdo + pdo_mysql.
Now, all that aside, it can be considered bad style to post the exact same message in multiple threads. If you feel that the same answer applies to two separate topics, you should post in one of them and then post a reference back in the other thread.
-
Dec 8, 2008, 17:15 #40
The design of PDO doesn't bother me as much as the stuff it cannot do.
Simple things like binding a short binary string to a parameter is impossible. Even though its in the standard SQL and RDBMs can do it.
Code:INSERT INTO hashes(hash) VALUES(X'0123456789abcdef');
-
Dec 9, 2008, 13:39 #41
- Join Date
- May 2007
- Location
- Poole, UK
- Posts
- 5,077
- Mentioned
- 103 Post(s)
- Tagged
- 0 Thread(s)
I just had a look at the code for Joomla and wordpress and neither use PDO, both access mysql direct with both of them being used by many sites I don't think it can really be considered to be a new standard. I can't look at what invison powerboards or vBulletin use, anyone know?
Community Team Advisor
Forum Guidelines: Posting FAQ Signatures FAQ Self Promotion FAQ
Help the Mods: What's Fluff? Report Fluff/Spam to a Moderator
-
Dec 9, 2008, 13:51 #42
- Join Date
- Dec 2002
- Location
- Ann Arbor, MI (USA)
- Posts
- 648
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
-
Dec 9, 2008, 14:40 #43
- Join Date
- Jan 2005
- Location
- heaven
- Posts
- 953
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Joomla, wordpress, and vbulletin were running on PHP 4.x servers well before there was a PHP 5 came along with the goodness of PDO. There are millions of websites out there that use antiquated code - maybe antiquated is too harsh of a word - so if quantity defines standard, then using the mysql functions are the standard. Pick up any book on learning PHP or run a search for PHP & MySQL tutorials, and hands down you will find more using the mysql functions over PDO so I think it's fair to say that the old way is still very much a standard even with the rising popularity of PDO.
Creativity knows no other restraint than the
confines of a small mind. - Me
Geekly Humor
Oh baby! Check out the design patterns on that framework!
-
Dec 9, 2008, 15:51 #44
- Join Date
- Feb 2008
- Location
- end($world)
- Posts
- 834
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
-
Dec 9, 2008, 17:15 #45
- Join Date
- Jan 2005
- Location
- heaven
- Posts
- 953
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
-
Dec 9, 2008, 17:26 #46
Symfony uses Propel which uses PDO now. Creole is dead.
http://creole.phpdb.org/trac/wiki/News/CreoleIsDead
-
Dec 9, 2008, 17:34 #47
- Join Date
- Feb 2008
- Location
- end($world)
- Posts
- 834
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Oh yes that's true, sorry for confusion.
But it seems newest Symfony also also offers Doctrine as alternative to Propel - http://www.symfony-project.org/book/doctrine/1_2/en/
Bookmarks