Re^3: Moose + ORM

And here is what it might look like ...


package Table;
use MooseX::Role::Parameterized;

parameter table_name => (
    isa      => 'Str',
    required => 1,
);

role {
    my $p = shift;

    my $table = $p->table_name;
    
    my $dbh   = DBI->connect( ... );
    my $sth   = $dbh->selectall_arrayref( "describe $table" );

    my @columns = ... do DBI magic here ...

    foreach my $col (@column) {
        has $col->{name} => (
            is      => 'rw',
            isa     => $col->{type},
            default => $col->{default},
        );
    }
};

package MyTable;
use Moose;

with 'Table' => { table_name => 'my_table' };
[download]

-stvn

Comment on Re^3: Moose + ORM Download Code

Replies are listed 'Best First'.
Re^4: Moose + ORM by Anonymous Monk on Jul 24, 2009 at 12:58 UTC
Thank you very much for this. I tinkered around with my code last night and realized that I should not be exporting like that. This is what I came up with: Read more... (2 kB) I wonder what kind of contracts I am breaking with any class that wants to use this ... but it seems to work. The trick is loading the data into the object after it has been defined. Question if you have the gumption ... how would you handle loading the data? How would you pass the unique identifier of the database table row to be loaded into your MooseX::Role::Parameterized solution? That's the trouble I seem to have now, and hence why I added the Table::Loader role. Thanks again!	[reply] [d/l]
Re^5: Moose + ORM by stvn (Monsignor) on Jul 24, 2009 at 17:15 UTC
Question if you have the gumption ... how would you handle loading the data? Honestly, I would have used DBIx::Class or Fey::ORM. I wrote my own ORM years ago when SPOPS was state of the art and Class::DBI was still very much an ugly/dirty hack. I won't ever write one again, it is a solved problem and I have no interest in re-inventing that wheel. First, it is very much not recommended to put a BUILD method in roles because it could get overridden by a local class version. You should do a before/after/around for BUILD instead, which will do what you want it to do. Second, I would get rid of the BUILD method anyway and put the load function into the role and then call `MyTable->load( id => 1 )` to get things from the DB, because using `new` to fetch from the database is misleading since it is not creating a new instance, but loading an old one. -stvn	[reply] [d/l] [select]
Re^6: Moose + ORM by Anonymous Monk on Jul 24, 2009 at 20:38 UTC
Would you have used one of those two modules inside a Moose role? Or would you not use Moose at all? Thank you so very much for your BUILD suggestions ... I took a stab at implementing them and broke my code horribly. :) Third time is a charm ... so I'll take a rest before I attempt my second try. ;)	[reply]
Re^7: Moose + ORM by stvn (Monsignor) on Jul 24, 2009 at 21:02 UTC
Re^8: Moose + ORM by Anonymous Monk on Jul 27, 2009 at 14:29 UTC
Re^8: Moose + ORM by Anonymous Monk on Aug 05, 2009 at 20:12 UTC
Some notes below your chosen depth have not been shown here
Re^4: Moose + ORM by metaperl (Curate) on Jul 24, 2009 at 12:57 UTC
The issues of connecting to a database need to be resolved in a configurable flexible way "The future of DBIx::Class talk" covers that syntax (32 minutes in) Maybe you could contribute to that. Joins need to be solved? If you just want an easy access to one table, maybe Tie::DBI is enough?	[reply]
Re^5: Moose + ORM by Anonymous Monk on Jul 24, 2009 at 13:45 UTC
I have #1 covered for my needs, but going forward as a CPAN module then yes, this needs to be solved. I'll check out the video. this can be solved by someone else, thank you. :) I personally think this is mostly a waste of time and can be handled by writing custom methods with optimized SQL. But when the day comes that someone actually solves this problem in a 100% reusable manner, I'll use it. :) this seems very unappealing -- the idea is to make a Moose role. Feel free to write an example that works with Moose if you really think I missed the point.	[reply]