SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 47 of 47
  1. #26
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    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

  2. #27
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    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.

  3. #28
    SitePoint Evangelist ghurtado's Avatar
    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

  4. #29
    SitePoint Addict Mastodont's Avatar
    Join Date
    Mar 2007
    Location
    Czech Republic
    Posts
    375
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    using constants as arguments is just bad style.
    So - for example - filter_var with constants as options is a bad design? Preg_split? Array_multisort? Do you prefer to remember integer values for arguments? I don't.

  5. #30
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Mastodont View Post
    Do you prefer to remember integer values for arguments? I don't.
    No, I prefer separate methods, if the semantics differ. I like $pdo->getFoo() over $pdo->get(PDO::FOO)

  6. #31
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    689
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    No, I prefer separate methods, if the semantics differ. I like $pdo->getFoo() over $pdo->get(PDO::FOO)
    But what happens when you encounter:
    $pdo->get(PDO::FOO | PDO::BAR);
    Now you need:
    $pdo->getFoo();
    $pdo->getBar();
    $pdo->getFooBar();

    I just wrap the pdo objects in my own access object and hide all the constants in it.

  7. #32
    simple tester McGruff's Avatar
    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.

  8. #33
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    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

  9. #34
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff View Post
    The constants could be tamed with, in order of preference:
    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

  10. #35
    We're from teh basements.
    Join Date
    Apr 2007
    Posts
    1,205
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff View Post
    There are four query methods because there are four different types of result: simple boolean with eg a create database query, a hash when you know a select query will only return one row, an iterator when you know it might not, and a (possibly badly-named) method to manipulate tables eg inserts & updates which will return the number of affected rows.

    PHP Code:
        function query($sql);  // returns bool
        
    function getRow($sql); // returns array
        
    function getRows($sql);  // returns iterator
        
    function manipulateRows($sql);  // returns int 
    Another option would be to have a single query() method, parse the sql to discover the query type, and then return the appropriate type. At the time (it was a long time ago) I decided that was too much hard work and instead opted for different methods for different types of sql query. A single query method is certainly do-able and would present a simpler interface but it would return different things in response to different queries....
    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.

  11. #36
    SitePoint Evangelist
    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,
    Alex
    The only constant in software is change itself

  12. #37
    From space with love silver trophy
    SpacePhoenix's Avatar
    Join Date
    May 2007
    Location
    Poole, UK
    Posts
    5,030
    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

  13. #38
    SitePoint Evangelist
    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 is a binary extension...so while there is a slight over head...honestly the performance loss is minimal, considering you get data access abstraction.

    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.
    What, you mean manually, so a programmer can forget and have a SQLi injection occur because of human error? :P

    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
    That is why PDO is said to be a data access layer not a database abstraction layer...besides it could be used in conjunciton with an OQL which would then offer a complete and robust database abstraction layer. You would be able to literally and seamlessly switch RDBMS with the flip of a switch. That is the eventual goal of Rapid Database.

    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
    If you know you are always going to use MySQL sure...but most developers (for one reason or another) like the option of being able to make the switch. I always use MySQL (I have never used another database in fact -- other than Access or SQLite) but I still prefer PDO "just in case".

    Cheers,
    Alex
    The only constant in software is change itself

  14. #39
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    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.

    Quote Originally Posted by SpacePhoenix View Post
    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.
    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.

    Quote Originally Posted by SpacePhoenix View Post
    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.
    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?

    Quote Originally Posted by SpacePhoenix View Post
    Each database has it's own variations of SQL, until all databases use exactly the same SQL command set, in exactly the same way.
    PDO is not a database abstraction layer. It's a database connectivity layer.

    Quote Originally Posted by SpacePhoenix View Post
    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.
    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.

  15. #40
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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');
    So had to resort to own parameter handling with the specific database APIs.

  16. #41
    From space with love silver trophy
    SpacePhoenix's Avatar
    Join Date
    May 2007
    Location
    Poole, UK
    Posts
    5,030
    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

  17. #42
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by SpacePhoenix View Post
    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?
    I'm not suprised that they would be slow to move to PDO, considering they're all CMSs or Forums that are aimed towards users, not developers. A better indicator would be what the popular PHP frameworks support.

  18. #43
    SitePoint Guru
    Join Date
    Jan 2005
    Location
    heaven
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by SpacePhoenix View Post
    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?
    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!

  19. #44
    SitePoint Guru risoknop's Avatar
    Join Date
    Feb 2008
    Location
    end($world)
    Posts
    834
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by allspiritseve View Post
    I'm not suprised that they would be slow to move to PDO, considering they're all CMSs or Forums that are aimed towards users, not developers. A better indicator would be what the popular PHP frameworks support.
    Symfony is using Creole (though latest version already uses Doctrine I think). Anybody knows what Zend uses?

  20. #45
    SitePoint Guru
    Join Date
    Jan 2005
    Location
    heaven
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by risoknop View Post
    Symfony is using Creole (though latest version already uses Doctrine I think). Anybody knows what Zend uses?
    Zend_Db using PDO and MySQLi for mysql databases.
    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!

  21. #46
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by risoknop View Post
    Symfony is using Creole (though latest version already uses Doctrine I think). Anybody knows what Zend uses?
    Symfony uses Propel which uses PDO now. Creole is dead.
    http://creole.phpdb.org/trac/wiki/News/CreoleIsDead
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  22. #47
    SitePoint Guru risoknop's Avatar
    Join Date
    Feb 2008
    Location
    end($world)
    Posts
    834
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by logic_earth View Post
    Symfony uses Propel which uses PDO now. Creole is dead.
    http://creole.phpdb.org/trac/wiki/News/CreoleIsDead
    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •