I'm digging Class::DBI::mysql

Lecar_red on 2005-04-21T20:20:14

I've been really digging Class::DBI and Class::DBI::mysql.



In a master class (or whatever that main thing would be called), I've been able to do:

RSSManager::DBI->table('feeds'); 
RSSManager::DBI->create_table(q{
  id MEDIUM INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
  userid INT,
  url varchar(256),
});

RSSManager::DBI->set_up_table;

Instead of mysql < setup_my_stuff.sql and other crap...
Very cool. This isn't even mention the easy column -> method mapping...



Thanks, Tony!

---

Re: create_table

rhesa on 2005-04-21T23:52:38

Yeah, this totally cool. I'm always keeping my table definitions in all my classes like that. No more out-of-date sql files!

BTW, in production code I add this to my base class:

        *create_table = sub() {0};

It makes the call a no-op, and that's nice for performance (at least on startup). And it's very very simple.

Re: create_table

grantm on 2005-04-22T02:08:59

Does that have any different an effect from:

sub create_table() {0}

?

Re: create_table

rhesa on 2005-04-22T10:15:16

I was under the impression that it wouldn't trigger warnings, but it does. So there's no difference apparently.

I now have this:

{
    no warnings 'redefine', 'prototype';
    sub create_table() {0}
}

I'm still a little puzzled by the prototype, though. I seem to remember that this way would get optimized away, so that not even the arguments to the sub would be evaluated. But I'm wrong about that, apparently.

Re: create_table

merlyn on 2005-04-22T14:24:06

Maybe if you put it in a BEGIN block instead of a naked block? And/or ahead of your "use Class::DBI::mysql". The problem is that you're compiling some use of that subroutine before you're compiling this code.