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

[Nilson Santos Figueiredo Junior]

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.

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

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

Of course, I think we could both be satisfied, so that you could code
it the way you suggested, *or* inside each of the classes you could
call

  table {
    name 'foo_bar'; # optional, autosetup if not present

    column 'id' => AutoId(); # data_type => 'integer', size => 16,
                             # is_auto_increment => 1
    column 'name' => (String(), Optional(), size => 128);
                             # String() gives data_type => varchar
                             # Optional() gives is_nullable => 1

    ...
  };

with the class name being implicit to the current class.

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

> Exactly how relationships are expressed, I'm not sure. I'd quite like to be
> able to just say something like (stealing from Mooose.pm)
>
> has 'bazquux' => (isa => 'BazQuux', reverse => 'foobars');
>
> and have that automatically add whatever columns are required to the table and
> set up a belongs_to rel (and a has_many 'foobars' on the other side).

In order to support this sort of "clean" syntax without parens (which
I like, too) you'd probably need to do some exporting magic, I think.

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.

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

-Nilson Santos F. Jr.