in reply to DBD::Mock and DBD-specific attributes
You wont find that attribute in DBD::Mock since its specific to DBD::mysql. This is an interesting issue, and one that DBD::Mock should address. It actually seems like I might be taking over the maintance of this module from lachoy, so I will give some thought to how to address this. Any thoughts/suggestions on how you would like it to work are welcome.
Re^2: DBD::Mock and DBD-specific attributes
by dragonchild (Archbishop) on Aug 16, 2004 at 18:26 UTC
|
Regardless of how it works under the hood, if I set an attribute to $x, then ask for that attribute back, I should get $x, unless the docs indicate that the given attribute does something based on $x.
Plus, in looking under the hood, DBD::Mock::db::STORE() calls to SUPER::STORE if it doesn't know about the attribute. From what I can discern (and from what I think DBI::DBD says), the attribute and value should be stored in the tied hash.
Now, an interesting possibility to add to DBD::Mock would be an 'is_mocking' attribute in the connection parameters. So, I might want to say something like:
my $dbh = DBI->connect( 'dbi:Mock:is_mocking=mysql', '', '' ) or die $
+DBI::errstr;
And, there would be a DBD::Mock::mysql that would do the right thing with mysql_insertid (or DBD::Mock::Oracle with an ora_* attribute, etc.)
------
We are the carpenters and bricklayers of the Information Age.
Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose
I shouldn't have to say this, but any code, unless otherwise stated, is untested
| [reply] [d/l] |
|
| [reply] |
|
That's why I would strongly suggest the usage of something like DBD::Mock::mysql and the like. More in another reply in this thread.
------
We are the carpenters and bricklayers of the Information Age.
Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose
I shouldn't have to say this, but any code, unless otherwise stated, is untested
| [reply] |
|
After looking more closely at the source of DBD::Mock, I agree, it should work as you expect. After reading DBI::DBD I am convinced it should work as you expect. However, it does not. The really weird part of course is that it seems to works for other attributes like PrintError, RaiseError, etc. I am trying to figure it out right now, I will keep you updated.
UPDATE
Found this in the trace output:
$h->{'mysql_insertid'}=10 ignored for invalid driver-specific attribut
+e
So it seems that DBI will skip over driver specific attributes. According to line 1554 of DBI.xs, only those attributes that start with 'private_', 'dbi_' or 'dbd_' are allowed, all others are ignored. However, this seems to contradict what it says in DBI::DBD
The DBI will actually store and fetch driver-specific attributes (with all lowercase names) without warning or error, so there's actually no need to implement driver-specific any code in your FETCH and STORE methods unless you need extra logic/checks, beyond getting or setting the value.
Hmmmm.
| [reply] [d/l] |
|
The really weird part of course is that it seems to works for other attributes like PrintError, RaiseError,
Upper-cased attribute names are reserved by DBI and should be passed by the driver to DBI for storing and fetching.
Lower-cased attribute names should start with *a* recognized prefix, not necessarily the prefix of the driver in question. Lower-cased attribute names that are not a recognized prefix (e.g. mock_ or mysql_ or csv_ are recognized) should never be used.
And I agree with your previous post that DBD::Mock is a special case so you may want to allow unknown attribute names (though still they aboslutely should have a known prefix).
| [reply] |
|
Other replies in this thread seem to indicate that lowercase attributes will not be handled unless they have the correct prefix. So, what about adding a check in the two STORE/FETCH subs in DBD::Mock to say "If I don't know about this attribute, but it is in lowercase, I'll store/fetch it for you."?
I went ahead and added this code to my copy and it passed my tests, though you'll probably want to design it a little better than my hackish solution. Specifically, doing a reset on the $dbh should probably delete all the added-on attributes. Plus, I would still like to see a way of mocking a given DBD.
------
We are the carpenters and bricklayers of the Information Age.
Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose
I shouldn't have to say this, but any code, unless otherwise stated, is untested
| [reply] |
|
|
|
Regardless of how it works under the hood, if I set an attribute to $x, then ask for that attribute back, I should get $x, unless the docs indicate that the given attribute does something based on $x.
No, not with databse handle attributes AFAIK. DBI leaves the handling of all lower_cased handle attributes (method attributes are a different thing) to the drivers. If you set an attribute that the driver doesn't know about, the driver shouldn't be expected to give it back to you. In fact, the driver probably shouldn't allow you to set it. stvn you might consider adding code to ::db::STORE that dies if someone tries to set an unknown attribute.
| [reply] |
|
stvn you might consider adding code to ::db::STORE that dies if someone tries to set an unknown attribute
I would agree with you in the context of a normal DBD, but with DBD::Mock, the ability to catch and store driver specific attributes is probably a feature more than it is a bug. I am still thinking about the best way to handle this.
| [reply] |
|
|