in reply to Re: MySQL Table Creation using DBI
in thread MySQL Table Creation using DBI

I've heard Class::DBI described as many things before... but never "complex whirlygig" :-)

(SPOPS or Alzabo on the other hand ;-)

update: above removed because I was foolish and misread the message hierarchy. Bad Adrian.

For example, to create the rows (assuming the DB table exists) you would just need something like (untested code):

#! /usr/bin/perl use strict; use warnings; package BackupJob; use base 'Class::DBI'; use CLASS; # the DB where you job table is CLASS->set_db('Main', 'dbi:mysql', 'username', 'password'); # the name of your job table CLASS->table('jobs'); # the columns in your table, primary key first CLASS->columns(All => qw( jobid class classtype client compression elapsed ended filelistcount files fileslastwritten group jobid jobpid jobtype kbytes kbyteslastwritten masterserver operation owner path percent priority retentionperiod retentionunits schedule schedule_type server started state status stunit subtype try try_1_elapsed try_1_ended try_1_fileswritten try_1_kbyteswritten try_1_pid try_1_server try_1_started try_1_status try_1_statuscoun +t try_1_statusdescription try_1_statuslines try_1_stunit trycount )); package main; # If we assume %JOBS us a has mapping # jobid => {column => value, column => value ...} # then the following will create a DB row for each # entry my ($jobid, $values); while ( ($jobid, $values) = each %JOBS ) { BackupJob->create({ jobid => $jobid, %$values }) or die };

The BackupJob object also gives you lots of other nice things like searching, accessors, etc for free. Nice Class::DBI :-)

(of course, one of the things that Class::DBI doesn't support is tables with multi-column primary keys - so its not a lot of use for the table example I gave earlier :-)

Replies are listed 'Best First'.
Re: Re: Re: MySQL Table Creation using DBI
by ignatz (Vicar) on Sep 05, 2002 at 12:19 UTC
    I was not replying to your post.

    If the poster is new to working with databases, then the best thing to do is to get comfortable with the most straitforward way of doing things, which is with SQL. Not a good idea to abstract out fundamental tools if you don't know how the fundamental tools work.

    ()-()
     \"/
      `                                                     
    

      Apologies for the misrepresentation. Misread the message hierarchy. Now fixed.

      You can certainly get in a horrible fix if you don't understand that tools like Class::DBI have limitations (the lack of support for multi-column primary keys being a case in point here).

      I think I could argue with the statement that SQL is the most straightforward way of doing the task - but I understand the sentiment ;-)

        <soapbox>
        If right out of the gate you are needing to create dynamic constantly changing scripted tables you need to step back and rethink your problem. You are trying to hard. It is easy to fall into the trap of treating tables as just another hash to manipulate. Your data is not mearly a tool that you use in your application. It is your foundation, and you need to keep your foundation as solid and simple as possible. Even The Sistine Chapel is built on a big boring block of rock.

        As someone who has spent a lot of time digging through other people's spaghetti code, there is nothing more horrible then abstract, dynamically generated SQL. Clear, simple, straitforward SQL is like a beacon in even the darkest of nights. Think long and hard before you try something more.

        </soapbox>

        /me goes back to his cave to lick his wounds from his last contract gig.

        ()-()
         \"/
          `