Page 1 of 1

How would you decompose the PDO interface?

Posted: Sat Dec 06, 2008 10:13 pm
by alex.barylski
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

Re: How would you decompose the PDO interface?

Posted: Sun Dec 07, 2008 12:51 am
by allspiritseve
Do you have a test case or something where we could see sample usage?

Re: How would you decompose the PDO interface?

Posted: Sun Dec 07, 2008 1:20 am
by alex.barylski
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

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

Re: How would you decompose the PDO interface?

Posted: Sun Dec 07, 2008 2:10 am
by allspiritseve
I myself like the existing api for PDO.

However, at a glance:

Code: Select all

$rdb->prepareQuery ('...');
Seems to me to be a little redundant. What else can you prepare? Why not

Code: Select all

$rdb->prepare ('...');

Code: Select all

$rdb->prepareParam ('...');
bindValue is already a bit long to type when you're binding lots of variables.. what about

Code: Select all

$rdb->set ('key',  $value);

Code: Select all

$rdb->executeStatement(null, $res);
Same thing, why not

Code: Select all

$rdb->execute (null, $res);
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.

Re: How would you decompose the PDO interface?

Posted: Sun Dec 07, 2008 2:15 am
by allspiritseve
Oh, also see this thread, particularly McGruff's comments: http://www.sitepoint.com/forums/showthread.php?t=574642

Re: How would you decompose the PDO interface?

Posted: Sun Dec 07, 2008 2:27 am
by alex.barylski
EDIT | SOunds as though McGruff has had the same problems I have...the API is a mess - that I would agree with. :P

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

Re: How would you decompose the PDO interface?

Posted: Sun Dec 07, 2008 2:03 pm
by alex.barylski
bindValue is already a bit long to type when you're binding lots of variables.. what about
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...

If I had several objects and they all had generic setters...

Code: Select all

$dbh->set('...')
Might be confusing and easily mis-typed as

Code: Select all

$obj->set('...');
Which might not raise an error and result in a very annoying bug.

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);
 
bindParam() is only typically used when you want to set a parameter once before a for loop (say a time() value to be used on each inserted record, instead of invoking time() on each iteration. The rest of the values you would pass in with the array as shown above.

Cheers,
Alex

Re: How would you decompose the PDO interface?

Posted: Sun Dec 07, 2008 11:14 pm
by josh
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.
:D

Re: How would you decompose the PDO interface?

Posted: Mon Dec 08, 2008 12:10 am
by alex.barylski
My editor supports source folding on comments so I simply hide all multi line comments by default...all I see is two lines... :P

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. :(