|
Re: DBX offers simplified access to the DBI
by adrianh (Chancellor) on Feb 19, 2003 at 11:10 UTC
|
Several comments:
I really don't think this warrants a new top-level namespace in CPAN. Especially since there is the DBIx:: space for exactly this sort of thing.
Also - have you looked at DBIx::AbstractLite, DBIx::Recordset, DBIx::Record, DBIx::TableHash, Class::DBI, etc. which all do very similar things.
I agree with the comments that others have made on the connection syntax. Naming the method after the database doesn't give you any obvious advantages. It gives you disadvantages because of possible method clashes and the need to eval code.
What is the disadvantage you see in having the database as a parameter to a connect method?
You could make your loops a little more compact if the query didn't fetch the first item and move_next returned false when there were no more records to be fetched. You could then write:
$rs = $conn->query("SELECT * FROM test");
while($rs->move_next)
{
print $rs->field("client") . "\n";
$rs->field("client", "test");
}
Finally, it only seems to work properly if you select * which is something many people never do since it's needlessly expensive when you only need some fields. | [reply]
[d/l]
[select] |
(jeffa) Re: DBX offers simplified access to the DBI
by jeffa (Bishop) on Feb 19, 2003 at 15:03 UTC
|
Two things:
Don't require your users to use Perl 5.8. Normally i just
throw the tar ball away and move on, but in the case of this
module i did a little source searching and found that
Constants.pm contained a Perl 5.8 specific: the newest
constant.pm module. "The most recent version '1.04' of the module 'constant' comes with the current version of perl
(5.8.0)."
use constant {DBX_CURSOR_RANDOM => 0, DBX_CURSOR_FORWARD => 1};
i recommend changing that code to the more backward compatible:
use constant DBX_CURSOR_RANDOM => 0;
use constant DBX_CURSOR_FORWARD => 1;
The second item is your use of AUTOLOAD in DBX.pm.
Always define a DESTROY subroutine, even if it is
empty and does nothing. When a DBX object is 'terminated',
AUTOLOAD will be needlessly called.
Finally, while i certainly do not mind this module being
available, i probably won't be using it for the same reasons
that rdfield, Tomte, and Aristotle mentioned. If i
want another abstraction, i use Class::DBI.
Someday i hope that Pixie will make it's way into
my production code (i think).
One reason i probably won't use your module is because i
really can't stand record pointer
style interfaces, they remind me too much of my SQL Server 7
days. >P
DBI's selectall_arrayref and
selectcol_arrayref have been more than enough for
me to get database work done. Most of the time i just ship
the resulting datastructures over to HTML::Template without
even knowing what the field names are.
Thanks for contributing though, i for one appreciate it. :)
jeffa
L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
| [reply]
[d/l]
[select] |
Re: DBX offers simplified access to the DBI
by dws (Chancellor) on Feb 19, 2003 at 04:28 UTC
|
Here's a sampling of the DBX's capabilities:
$conn = DBX->mysql( ...
When you hard-code the database, you close off the possibility of making the database configurable. (Which is still possible, if your queries are sufficiently generic.)
This doesn't look like a step in the right direction.
| [reply]
[d/l] |
|
|
When you hard-code the database, you close off the possibility of making the database configurable.
But seeing as how methods can be called dynamically this isn't much of an issue
my $conn = $DBX->$db( @info );
HTH
_________
broquaint | [reply]
[d/l] |
|
|
Nothing's hardcoded. You simply replace the 'mysql' with the name of your DBD driver. So, you could have just as easily said:
$conn = DBX->CSV(...
to use the DBD::CSV driver. Sorry if I didn't make that clear. | [reply]
[d/l] |
|
|
Nothing's hardcoded. You simply replace the 'mysql' with the name of your DBD driver.
If you have to change code, it's hard coded. That's what hard coded means.
Update: After looking up "hardcoded" in the Hacker's Dictionary, I see that it applies to constants. I should have said that the database is "hardwired", which is just as bad.
| [reply] |
|
|
|
|
|
Re: DBX offers simplified access to the DBI
by rdfield (Priest) on Feb 19, 2003 at 10:39 UTC
|
What's so hard about DBI that people feel they must develop abstractions? To me, they just make tracking down problems that much harder, which is never a good thing.rdfield | [reply] |
|
|
I agree completely.
chromatic wrote a nice article in defense of DBI a while ago for Perl.com, which is a useful starting point for any kind of abstraction.
Then you take another step and do to SQL in Perl what you'd do to HTML in Perl: push it out to templates. And there you go.
Actually, an added benefit of this approach is that you have total control over the SQL in use; you can hand off your templates to a DBA or whoever and they can tune them for you. That's not something you can usually do with autogenerated SQL.
Makeshifts last the longest.
| [reply] |
|
|
++rdfield; DBI is as much an abstraction as I see fit for DB interaction; perlish clean IMHO
Now there's nothing wrong in encapsulating DB-interaction in Objects, e.g. the way slash does it, for a certain application in a certain context.
A general abstraction into something 'more easy' is doomed to raise more problems in the long run; at least this is what my experience with java-apis tells me ;-)
regards,
tomte
| [reply] |