MySQL Parser understands VIEWs with a field list.

[adherzog]

Updates the MySQL parser to properly parse CREATE VIEW statements that
contain a field list after the view name. This allows the parser
to understand statements created by the MySQL producer.

Prior to this change, this statement would be parsed properly:

CREATE
  VIEW view_foo AS
    SELECT id, name FROM thing;

But this one would not:

CREATE
  VIEW view_foo (id, name) AS
    SELECT id, name FROM thing;

(The latter statement is the same one added to the tests in this PR. It's taken directly from the mysql producer tests.)

[ilmari]

An explicit field list overrides the names derived from the SELECT column list, so the field list needs to be saved here and stored in the fields attribute of the SQL::Translator::Schema::View object.

[adherzog]

It looks like the fields attribute of the view is generated based on the column aliases, so I'm setting the column aliases rather than explicitly setting the fields attribute.

[ilmari]

Sorry, I misread your statement, ignore the previous comment. It'd be easier to just store the fields in the %views hash and use that if present instead of the alias list in the ->add_view call in sub parse { … }.

[adherzog]

If we store the fields in the %views hash instead of setting the column aliases, then the generated SQL won't include the aliases. So I'm continuing to set the aliases, and both the generated SQL and the fields attribute are returning the correct results. (At least, according to the tests I added.)

I've used your simplified code (though I'm using $item{'parens_field_list(?)'}[0] instead of $item{'parens_field_list(?)'}, since it seems to be an arrayref within an arrayref) and left the rest the same.

@ilmari - Please review again when you have a chance.

[ilmari]

Please also test that the view is in fact correctly parsed and that the column names after the view name take precedence over the ones in the SELECT list.

[adherzog]

I've added better tests - it now checks VIEW statements that include 1) a field list, 2) aliases in the SELECT statement, and 3) both a field list and aliases. (When both are specified, I believe the field list should override the column aliases.)

[adherzog]

@ilmari Thanks for the review/feedback. I've updated the PR as you requested. Let me know if you seen any other errors or omissions.

[ilmari]

First of all, never use map in void context for side effects, use for instead.
Secondly, this all could be simplified to:

my @fields = @{$item{'parens_field_list(?)'} || []};
$select_sql->{columns}->[$_]->{alias} = $fields[$_]
    for 0..$#fields;

[ilmari]

More importantly, this is unnecessary if you instead store $item{'parens_field_list(?)'} in $views{$view_name}{fields} and use that in preference to the select aliases in the ->add_view call.

[adherzog]

If we store the fields in the %views hash instead of setting the column aliases, then the generated SQL won't include the aliases.

I've used your simplified code (though I'm using $item{'parens_field_list(?)'}[0] instead of $item{'parens_field_list(?)'}, since it seems to be an arrayref within an arrayref) and left the rest the same.