How would you decompose the PDO interface?
Moderator: General Moderators
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
How would you decompose the PDO interface?
I've worked with PDO for a little over a year and a bit and I still am not comfortable with it's API and still find myself frequently calling methods on a statement object instead of PDO and visa-versa.
I've just always been a little wary about the API and design. Yesterday I sat down and sketched out a new API design and today I have an implementation bundled in about a dozen classes.
Wouldn't mind hearing your remarks regarding it's design. Maybe spelling corrections, questions, comments, concerns, suggestions, PDO references, etc, etc.
I plan to eventually implement a OR/M solution and will probalby use this as a database access layer. It's essentially a more user-friendly wrapper around PDO, but you can use native PDO functions if you require.
I make some assumptions about design and use, for example I favour resultsets as associative arrays never returning as numeric indicies. I also don't allow binding on references, only passed in by value -- the former led to some awkward bugs in my application so I have dropped that completely.
These assumptions have simplified the interface in some ways but the decomposition of the API also meant more classes, but these could easily be tied togather using a facade that meets your development style.
Google code wiki and a Cache result set needs work/finishing...but I figured I'd post here now anyways and get as much feedback as possible.
p.s-See signature for download details (Rapid Database)
Cheers,
Alex
I've just always been a little wary about the API and design. Yesterday I sat down and sketched out a new API design and today I have an implementation bundled in about a dozen classes.
Wouldn't mind hearing your remarks regarding it's design. Maybe spelling corrections, questions, comments, concerns, suggestions, PDO references, etc, etc.
I plan to eventually implement a OR/M solution and will probalby use this as a database access layer. It's essentially a more user-friendly wrapper around PDO, but you can use native PDO functions if you require.
I make some assumptions about design and use, for example I favour resultsets as associative arrays never returning as numeric indicies. I also don't allow binding on references, only passed in by value -- the former led to some awkward bugs in my application so I have dropped that completely.
These assumptions have simplified the interface in some ways but the decomposition of the API also meant more classes, but these could easily be tied togather using a facade that meets your development style.
Google code wiki and a Cache result set needs work/finishing...but I figured I'd post here now anyways and get as much feedback as possible.
p.s-See signature for download details (Rapid Database)
Cheers,
Alex
- allspiritseve
- DevNet Resident
- Posts: 1174
- Joined: Thu Mar 06, 2008 8:23 am
- Location: Ann Arbor, MI (USA)
Re: How would you decompose the PDO interface?
Do you have a test case or something where we could see sample usage?
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: How would you decompose the PDO interface?
I document the usage a little using the Wiki:
http://code.google.com/p/pdowrapper/w/list
Alternatively you can look at the index.php in the truck, which should demonstrate the basics and/or gist of the idea:
http://code.google.com/p/pdowrapper/sou ... /index.php
I guess everyone always thinks their code is super simple and forgets that anything in more than a single file usually needs explaining
p.s-I wasn't just looking for code review though...more like a comparison of notes on how YOU might decompose the existing API and what interfaces you might discover, perhaps different or in addition to my own. At this point any feedback is better than no feedback.
Cheers,
Alex
http://code.google.com/p/pdowrapper/w/list
Alternatively you can look at the index.php in the truck, which should demonstrate the basics and/or gist of the idea:
http://code.google.com/p/pdowrapper/sou ... /index.php
I guess everyone always thinks their code is super simple and forgets that anything in more than a single file usually needs explaining
p.s-I wasn't just looking for code review though...more like a comparison of notes on how YOU might decompose the existing API and what interfaces you might discover, perhaps different or in addition to my own. At this point any feedback is better than no feedback.
Cheers,
Alex
- allspiritseve
- DevNet Resident
- Posts: 1174
- Joined: Thu Mar 06, 2008 8:23 am
- Location: Ann Arbor, MI (USA)
Re: How would you decompose the PDO interface?
I myself like the existing api for PDO.
However, at a glance:
Seems to me to be a little redundant. What else can you prepare? Why not
bindValue is already a bit long to type when you're binding lots of variables.. what about
Same thing, why not
I guess my overall goal if I were to wrap PDO would be short, succinct methods that were easy to type, since they get typed often.
However, at a glance:
Code: Select all
$rdb->prepareQuery ('...');Code: Select all
$rdb->prepare ('...');Code: Select all
$rdb->prepareParam ('...');Code: Select all
$rdb->set ('key', $value);Code: Select all
$rdb->executeStatement(null, $res);Code: Select all
$rdb->execute (null, $res);- allspiritseve
- DevNet Resident
- Posts: 1174
- Joined: Thu Mar 06, 2008 8:23 am
- Location: Ann Arbor, MI (USA)
Re: How would you decompose the PDO interface?
Oh, also see this thread, particularly McGruff's comments: http://www.sitepoint.com/forums/showthread.php?t=574642
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: How would you decompose the PDO interface?
EDIT | SOunds as though McGruff has had the same problems I have...the API is a mess - that I would agree with. 
I'll be sure to re McGruff's comments on SitePoint.
I always use full descriptive names for variables and methods, class names, etc.
Perhaps a personal choice, but I guess that was the motivating factor in re-designing it.
I personally have no problme styping out long winded tokens...as long as they make sense is what matters to me.
Cheers,
Alex
I'll be sure to re McGruff's comments on SitePoint.
I always use full descriptive names for variables and methods, class names, etc.
Perhaps a personal choice, but I guess that was the motivating factor in re-designing it.
I personally have no problme styping out long winded tokens...as long as they make sense is what matters to me.
Cheers,
Alex
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: How would you decompose the PDO interface?
bindParam() I believe is the name I selected to allow users to provide name/value pairs to a prepared statement...but the name is clear...bindValue is already a bit long to type when you're binding lots of variables.. what about
If I had several objects and they all had generic setters...
Code: Select all
$dbh->set('...')Code: Select all
$obj->set('...');Secondly...bindParam() is long winded but you could alternatively pass the name/value pairs into the execute() method in place of NULL.
Code: Select all
$name = 'Alexander';
$rdb->prepareQuery('SELECT * FROM table WHERE name = :name');
$rdb->executeStatement(array(':name' => $name), $res);
Cheers,
Alex
Re: How would you decompose the PDO interface?
60 line doc-block. el-oh-el

PCSpectra wrote:Again, I think comments are mostly a habit from Yesterday's programmers teaching Today's youth.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: How would you decompose the PDO interface?
My editor supports source folding on comments so I simply hide all multi line comments by default...all I see is two lines... 
Sorry, but you can easily remove it...
One issue I just ran into (I've made a few changes since commiting to google) is that using Cache resultset one a single record doesnt' seem to flush the resultset, so I get an error suggesting I use MYSQL buffered queries...which I am...setting it at connection and at statement preparation time but still I get that error. Ugh.
I only selected a single row but I probably have to move the internal pointer by one calling next() in the calling code...ideally I would have that wrapped up in the Cache object though...so I can swap between cache and array seamlessly without hassle.
Sorry, but you can easily remove it...
One issue I just ran into (I've made a few changes since commiting to google) is that using Cache resultset one a single record doesnt' seem to flush the resultset, so I get an error suggesting I use MYSQL buffered queries...which I am...setting it at connection and at statement preparation time but still I get that error. Ugh.
I only selected a single row but I probably have to move the internal pointer by one calling next() in the calling code...ideally I would have that wrapped up in the Cache object though...so I can swap between cache and array seamlessly without hassle.