On 4/3/06, Matt S Trout <[EMAIL PROTECTED]> 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. _______________________________________________ List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class Wiki: http://dbix-class.shadowcatsystems.co.uk/ IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
