feat: generate composite indexes for migrations

[ghostwriter]

• add composite indexes _unique, _index, _primary (prefixed with _ to avoid possibly overwriting table names).
• support multiple definitions of each type with space ( ) between.
• resolves Support for composite indexes #271

draft.yml

models:
  Participation:
    project_id: bigInteger
    team_id: bigInteger
    user_id: bigInteger
    name: string
    _unique: project_id,user_id team_id,project_id
    _index: project_id,user_id
    _primary: project_id,user_id

Output:

Schema::create('participations', function (Blueprint $table) {
    $table->id();
    $table->bigInteger('project_id');
    $table->bigInteger('team_id');
    $table->bigInteger('user_id');
    $table->string('name');
    $table->unique(['project_id', 'user_id']);
    $table->unique(['team_id', 'project_id']);
    $table->index(['project_id', 'user_id']);
    $table->primary(['project_id', 'user_id']);
    $table->timestamps();
});

[jasonmccreary]

Why not use id instead of bigInteger? Was this just for example, or an actual requirement to using composite keys?

[ghostwriter]

I just copied the draft file from the issue, it’s not a requirement.

[jasonmccreary]

Cool. Yeah, I'm not a fan of this syntax. I'm going to merge it for the rare cases some might use it. But probably won't document it.

More thinking about improvements for v2. It's possible some kind of meta or _ property is going to be needed for these definitions to define things like keys, relationships, policies, middleware.

[jasonmccreary]

I decided to move forward with the syntax similar to relationships for now, again, in v2 we will likely revisit this syntax by introducing some kind of "meta" key.

[mahfoudfx]

Hello,
I'm actually using this syntax and it works perfectly, awaiting for V2. Nevertheless, Ithink that this feature will face another consideration regarding the index name length.
On a project, I had to specify a composite key with 4 columns, I faced the MySQL error 1059 (Identifier name is too long) and it cannot be increased on the DBMS.
Currently, a default usage of the command blueprint:build will not handle this case, especially using naming standard for indexes (table.column), the easyiest way is to shorten the table and/or columns names.

[jasonmccreary]

@mahfoudfx, that issue is outside the scope of Blueprint.