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

[Matt S Trout]

Nilson Santos Figueiredo Junior wrote:
> On 4/3/06, Matt S Trout <dbix-class at trout.me.uk> wrote:
>> But it wasn't an RFC - an RFC is something you do *before* the fact, not after.
> 
> Well, I think uploading it to CPAN - even if subject to changes -
> would be something good. Apparently it's not. The uploaded version
> was, by no means, final nor complete. But, as I said, I'll try to
> follow some of your recommendations.

I'm all in favour of people writing their own extensions and submitting them 
to CPAN, but I'd rather they were commented on, cleaned up etc. first, and I'd 
really really prefer if they were kept in dbic svn so the dbic dev team can 
apply bugfixes if the original author vanishes.

The Class::DBI::Plugin namespace is an absolute quagmire, and I'd like to 
avoid that happening to DBIx::Class. We already have the spectacularly awful 
QueriesTime module on CPAN to demonstrate that (and if I see more like that 
I'll probably end up adding an "explicitly disrecommended extensions" section 
to the core docs).

>> And given we've been in the middle of discussion about improvements to
>> DBIx::Class, it would have been nice if you'd joined in the discussion first.
> 
> Well, maybe then I'm to blame, but I've joined this list only 4 days
> ago and didn't notice that much of a discussion regarding this aspect
> (of course, maybe I missed something).

There was one post mentioning a declarative syntax in response to my "so, what 
features do we want" post. Then nobody replied to it. The discussion appears 
to have ended up here instead. Shrug :)

>> I'd quite like to get rid of the classmethod declaration style in favour of
>> something more elegant, but we need to nail out the syntax first.
> 
> The syntax you suggested seems pretty nice. You seem to prefer
> everything declared in the schema, so the actual classes wouldn't even
> need to exist physically for the simple cases. Or did I get it wrong?

I'd like to support both, preferably both at once (i.e. some classes declared 
in the schema, some not)

> I actually prefer stuff such as column definition spread accross each
> of the classes. I think this is easier to cope with, when programming.
> And I also think it leads to better modularity, since with the "schema
> specifies everything" approach, it's centralized in one point.

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.

> I think this would be a nice approach. Of course, a solution without
> the table() would still be a bit cleaner, IMO.

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 ...

> However, I think that the current way of specifying relationships, but
> in a declarative and clean way would suffice:
> 
>   table {
>     belongs_to 'something' => 'Some::Class', 'something_id';
>   }
> 
> I'd just add some sane defaults (i.e. specify a convention or do some
> clever magic), so that you could omit the third and maybe the second
> parameter in most of the cases.
> 
> So you could use it like
> 
>   table {
>     belongs_to 'something';
>   }
> 
> And it would assume the second parameter as being
> "Current::Schema::Something" and the third parameters as being
> "something_id". Of course, the 3-parameter form would still be
> supported.

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.

> I also think we could borrow a page from Rails' ActiveRecord and
> implement relationships "through" other relationships, e.g., if a
> Company has many Clients and Clients have many Invoices, you could
> define something along the lines of:
> 
>   has_many 'clients';
>   has_many 'invoices', -through => 'clients';
> 
> But this is the least important of all of this, I think (it might even
> already exist a simple way to do this, but I couldn't find it -
> hand-coding was my only solution).

Actually, the many_to_many helper is basically just a relationship bridge, so 
that would do do the trick I guess. At some stage we should sort out a better 
many-many API with some helper stuff and take what's currently in there out 
into a bridge_relationships routine or so.

-- 
      Matt S Trout       Offering custom development, consultancy and support
   Technical Director    contracts for Catalyst, DBIx::Class and BAST. Contact
Shadowcat Systems Ltd.  mst (at) shadowcatsystems.co.uk for more information

+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +