Make sure custom relations work out with new alias strictness.

[dereuromark]

Refs #1012

So basically 5.1 and the more strict relation-handling ("Association alias Countries is already set") kinda broke the non documented feature of custom relationship baking.
Even though it was just baked wrongly with always the same Countries relation.

This PR adds the expected aliasing (back) ensuring there is no collision, and having the correct name in the process for most cases:

[
  'belongsTo' => [
    (int) 0 => [
      'alias' => 'Countries',
      'foreignKey' => 'country_id',
      'className' => 'Countries'
    ],
    (int) 1 => [
      'alias' => 'BillingCountries',
      'foreignKey' => 'billing_country_id',
      'className' => 'Countries'
    ],
    (int) 2 => [
      'alias' => 'ShippingCountries',
      'foreignKey' => 'shipping_country_id',
      'className' => 'Countries'
    ]
  ],
  'hasOne' => [],
  'hasMany' => [],
  'belongsToMany' => []
]

as example for

Countries

• id

Users

• id
• country_id
• billing_country_id
• shipping_country_id

[dereuromark]

It actually works:

        $this->belongsTo('Countries', [
            'foreignKey' => 'country_id',
            'className' => 'Countries',
        ]);
        $this->belongsTo('BillingCountries', [
            'foreignKey' => 'billing_country_id',
            'className' => 'Countries',
        ]);
        $this->belongsTo('ShippingCountries', [
            'foreignKey' => 'shipping_country_id',
            'className' => 'Countries',
        ]);

Maybe someone wants to add a test case for it? E.g. @luizcmarin ?
You can also test it and confirm

[dereuromark]

Turns out there is already an existing test case that so far was already invalid (exception would have happened), and now working:
9631dd0

[dereuromark]

@ADmad I found a way to make it work.

[luizcmarin]

Maybe someone wants to add a test case for it? E.g. @luizcmarin ? You can also test it and confirm

#1018

[luizcmarin]

I created a small test with some tables where errors occur. You may want to take note of this inconvenience.

invoices.txt

[dereuromark]

I wonder if thats directly related to the issue here (was working before and now not)
It rather looks like a different topic and probably should be checked out independently (e.g. after merge of this).

[luizcmarin]

I wonder if thats directly related to the issue here (was working before and now not) It rather looks like a different topic and probably should be checked out independently (e.g. after merge of this).

In fact, bake never finished generating the files due to this problem. This also happened with other tables. I isolated these attached tables for you to test, if you wish. But it happens with others too. Does this happen to you?

I'll send you the full script, in case you want to try it.

kancats.txt

[dereuromark]

You need to actually share the commands you use
because the SQL table itself does not provide the info to replicate

For me both "bake all Countries" and then "bake all Users" works just fine now with the upgrade here.
Same for "Proposals" and "ProposalItems" of this schema.

So whats the concrete command that breaks, and what have been generated before, or if manually adjusted, what does that file look like before running bake.

Again: I am fairly certain this is outside the scope of this specific issue here, and should not block the relation fix for the current bug in the system.

[luizcmarin]

I do not rule out the possibility of errors here. Please, if everything is ok in your tests, continue. I will do new tests after updating.

The command I use is simply: " bin\cake bake all --everything". Nothing more than that.

[dereuromark]

I can partically reproduce it
The issue you are having is probably due to some invalid setup in your DB schema

    $this->hasMany('Proposals', [
        'foreignKey' => 'proposal_id',
        'className' => 'Invoices',
    ]);

This wrongly is a proposal_id, but should be something else at least to make clear this is from invoices table referenced, and also must always be different from the actual proposal_id since Proposals is their own table.
So you are creating on purpose a setup that bake everything cannot solve for you.
You need to fix your table setup here, e.g. use invoice_proposal_id or alike to make it unique.

[luizcmarin]

Thank you very much for the tip. This means more work for me and less for you :) :(...
I'll review my scheme. I think this solves everything.

[dereuromark]

Well, #1019 will make it easier for you once merged :)

[dereuromark]

All good? Can we squash merge?

[ADmad]

Looks good apart from the minor nitpick of function name.