[Dbix-class] RFC: DBIx::Class::Sweet

Nilson Santos Figueiredo Junior acid06 at gmail.com
Mon Apr 3 20:25:25 CEST 2006


On 4/3/06, Matt S Trout <dbix-class at trout.me.uk> wrote:
> Depends. For rapid prototyping it's extremely handy to be able to just dump it
> all into one file and then move things out later.

Yes. But after this rapid prototyping stage, I'd rather have it at each class.

> The big problem is that if you're going to be importing methods in order to
> make things a bit cleaner you have to be able to un-import them to avoid
> leaving the class namespace full of crap (or take the package
> My::Table::Schema sets up My::Table approach that Jifty::DBI does) - and the
> best hook for un-importing I can find is "when the block's been executed",
> unless you want to either expect the user to call 'declaration_done;' when
> they're finished or do something heinous involving source filters ...

I don't think this is that big of a deal, since the methods were
already "virtually" there through inheritance. But, as I said, the
code block wrapper is also reasonable.

> Yeah, my point is that (1) the columns need to be auto-created, (2) we have to
> deal with multi-col PKs transparently as well if possible.

Couldn't the columns be auto-created if they did not already exist?
If you had multi-column PKs then you'd need to specify them manually. E.g.

  has_many 'clients', -keys => [qw(client_id client_name)];

Might be a good syntax.

-Nilson Santos F. Jr.



More information about the Dbix-class mailing list