Look at Michael Schwern's Class::DBI on CPAN.
On 28-Jul-2000 Michael Nachbaur wrote:
> <Warn priority="low">
> <warning class="Off Topic"/>
> <warning class="Long"/>
> </Warn>
>
> I'm not exactly sure where to send this, but here it goes:
> Has anyone completed/started an abstract database class at all? I've written
> some for very specific applications, but I want a more general-purpose tool.
> I'm about to start development on one, but wanted to get feedback from the
> world-at-large to see what features you would want first (or if anyone has
> already started one).
>
> The classes I've created/used before, are like:
> my $order = new Order( oid => '1234567' );
> $order->fetch();
> foreach my $order_line ( $order->Lines ) {
> print $order_line->Description, $order_line->Price;
> }
>
> I'd like to interact with a database, update data, save data, etc. without
> having to actually call any SQL code. And, if I modify my database schema,
> I'd like the classes to automatically adapt.
>
> The way I've done this before, is create a series of classes with AUTOLOAD
> subs in them which intercept the name of the method being called, and then
> updating that specific field in the record.
>
> How I"d like to implement it would be to define an XML file with represents
> the way my data is structured in the database. This way, the objects can
> determine when to cache data, and when to commit its values to the database
> for maximum efficiency. An example could be:
> <schema name="mp3_site" database="DB0" database_vendor="Oracle"
> database_version="8.1.5" username="nachbaur" password="you_wish">
> <table name="artist" primary_key="id">
> <field name="name" type="varchar" size="256" options="not null">
> </table>
> <table name="album" primary_key="id">
> <field name="parent_id" references="artist" options="not null"/>
> <field name="name" type="varchar" size="256" options="not null"/>
> <field name="image" type="varchar" size="4000" />
> </table>
> <table name="track" primary_key="id">
> <field name="parent_id" references="album" options="not null"/>
> <field name="name" type="varchar" size="256" options="not null"/>
> <field name="filename" type="varchar" size="4000"/>
> <field name="filesize" type="integer"/>
> </table>
> </schema>
>
> Now, obviously thats not that perfect of an example (but I"m in a hurry,
> 'cause I need to go get some coffee), but it illustrates that the class could
> import that XML file, which defines the way it should interpret data. So, it
> could fetch a particular record, and depending on how you tell it to operate,
> it could suck down all the data that the inital record refers to, or could
> retrieve it as-needed.
>
> It may not operate as efficiently as possible by default, but would give much
> more flexibility to the programmer. I know that when I'm lazy, I don't want
> to bind all my values, and make sure I'm using optimized SQL statements
> (explain plan, and that sorta thing). With this, I could "pre-define" SQL
> statements in this XML file that are pre-optimized, and I can just say:
> $db->run('do_really_scarry_join', %options);
>
> Sory for the long message. Would anyone like a module like this, or would I
> be just wasting my time? Anyone already have something like this? Any
> feedback would be appreciated (except flames and spam).
>
> --man
> Michael A. Nachbaur (KE6WIA)
> mike(at)nachbaur(dot)com
> http://www.nachbaur.com
> "Only two things are infinite, the universe and human stupidity, and I'm not
> sure about the former." - Albert Einstein
--
Jason Bodnar + [EMAIL PROTECTED] + Team Linux
Oh, well, of course, everything looks bad if you remember it.
-- Homer Simpson
El Viaje Misterioso de Nuestro Homer
