Re: DBI Wrapper Feature Comparison
by samtregar (Abbot) on Apr 17, 2004 at 06:45 UTC
|
Perhaps you should add a column "Worth The Trouble", defined as whether the module is worth bothering with if you're comfortable writing SQL. I could give you a list of all of them I've looked at so you can fill in the "N"s!
-sam
| [reply] |
|
| [reply] |
|
| [reply] |
|
... whether the module is worth bothering with if you're comfortable writing SQL. ... all ... "N"s!
Is cross-platform typically not an issue for your projects, or do you just target the lowest common denominator supported by the DBMS types you're targeting?
For example, the syntax for selecting a subset of rows with limit and offset varies from one database server to another -- do you just not use it in your applications, or do you have some other way of managing this issue?
If you're building a fixed-site application for a single customer, this isn't really an issue, but if you're building something for widespread reuse, it's nice to be able to say fetch_select( ..., limit => 10, offset => 40 ) and have it automatically use "limit 10 offset 40" when on MySQL, or "ROWNUM" when on Oracle.
| [reply] |
|
What do you mean by cross-platform?
For instance the transactional semantics that Oracle uses differ from virtually any other database, do these modules correct for that?
For instance DBD::Sybase doesn't allow you to use placeholders with 2 open statement handles on the same database handle at the same time (because of race conditions). Do you run into bugs from that?
While I agree that it is nice to abstract away the details of the database, I'm also worried that the abstraction will leak. And in some ways an incompletely implemented feature is worse than a complete one because you rely on it - and get burned.
| [reply] |
|
|
|
|
|
Is cross-platform typically not an issue for your projects, or do you just target the lowest common denominator supported by the DBMS types you're targeting?
Cross-platform? Sure! Cross-DB? Not usually. Take, for example, Krang. It's proving to be very portable, due partly to the fact that MySQL is very portable. Installing MySQL is so easy that it's hardly a barrier to adoption.
Supporting multiple databases in an application is very rarely worth the trouble, in my opinion. I say choose a good free database with wide portability and damn the rest.
-sam
| [reply] |
|
Yeah, good point. Hey, now that I think about it, I'm pretty comfortable with HTML, so I guess I can drop that silly templating tool I keep hauling out. Damn, my apps are gonna be fast if I just print() it directly from the code!
| [reply] |
|
| [reply] |
|
|
|
|
Re: DBI Wrapper Feature Comparison
by simonm (Vicar) on Apr 17, 2004 at 15:20 UTC
|
Thanks to blokhead for pointing out his Class::Tables; I don't know how I missed it before but will add it to the next version.
Package | DBI Wrapper | One Call | Data SQL | Named Config | Schema Access | DBMS Portability | Object Mapping
|
---|
Class::Table | Y | Y | Y/- | - | Y | Y | Y
| | [reply] |
Re: DBI Wrapper Feature Comparison
by Juerd (Abbot) on Apr 17, 2004 at 20:57 UTC
|
Nice additions to this table would be:
- Interface. Object oriented or functional? Are the method or function names perlish?
- DBD support. Are only certain DBDs supported or does it work with any existing DBD?
- DSN abstraction. Is the DSN abstracted or does it use normal DBI DSNs?
- Access to internals. So they wrap, but can you access the DBHs and STHs? If you can't access the STH directly, can you access its attributes?
- Multiple connections. Does the interface allow you to use multiple databases? How is this done? (OO? select-ish? both?)
- Multiple queries. Can multiple results from multiple queries be fetched or is there only one current STH? Can you use STHs from different databases, if multiple connections are supported?
To answer these for DBIx::Simple: OO; any; DBI; Current version: no, 1.20 and newer: yes, yes; yes(OO); yes, yes.
1.20 will be out Real Soon Now. (If you want to test the development version, let me know)
| [reply] |
DBIx::Recordset
by Arunbear (Prior) on Apr 17, 2004 at 19:41 UTC
|
DBIx::Recordset does NOT do Object Mapping - it provides access to records via tied arrays and hashes but not via objects (whose methods map to columns). | [reply] |
|
Point taken; I'll make that clearer in the next version.
| [reply] |
Re: DBI Wrapper Feature Comparison
by jZed (Prior) on Apr 17, 2004 at 17:23 UTC
|
Thanks for a most excellent post! Perhaps Tie::DBI belongs on the list. | [reply] |
|
| [reply] |
Sql::Simple
by dextius (Monk) on Apr 18, 2004 at 00:39 UTC
|
Table joins was the only thing that beat me down when I used to use Class::DBI (that and some instability issues when I used it under mod_perl).
I've been asked to write more comparison related information in my documentation for Sql::Simple, not realizing how many people are trying to solve this irritating problem.
Any sql module that lets you treat a database as a large data structure to do something wacky like any kind of transform is cool. (imho) Nice post.
cheers,
Ryan Dietrich (my friends call me dextius) | [reply] |
Re: DBI Wrapper Feature Comparison
by water (Deacon) on Apr 17, 2004 at 19:15 UTC
|
Obviously preaching to the choir here, but I'm still amazed by the TIMTOWTDI-ness of perl... this most helpful chart is one of the best illustrations of this (rich? crazy? fiercely independent? idiosyncratic? troubling? lovable?) facet of the perl community, indeed. | [reply] |