Idea: foreign() / references()

[robsontenorio]

Just like Laravel migrations it would be useful:

<?php

namespace App;

use Deiucanta\Smart\Field;
use Deiucanta\Smart\Model;

class Product extends Model
{
    public function fields()
    {
        return [
            Field::make('id')->increments(),
            Field::make('user_id')
                  ->unsignedInteger()
                  ->references('id')
                  ->on('users');
        ];
    }
}

[deiucanta]

@robsontenorio good idea :)

It might be even better to have it in the same method

Field::make('user_id')->unsignedInteger()->references('users.id');

Field::make('user_id')->unsignedInteger()->references('users', 'id');

Field::make('user_id')->unsignedInteger()->references(User::class, 'id');

What about deleting on cascade? Do you use db level deletion or you delete related entities in the app?

[robsontenorio]

I don’t use DB level deletion.

I just suggest the same syntax of Laravel migration just for consistency with well known methods from Laravel.

[robsontenorio]

@deiucanta I think this is a pretty important issue. A must have.

Without this we can't guarantee FK constraints out of box for smart migrations, and would be necessary do it manually editing files (boring).

About syntax i do prefer.

Field::make('user_id')->unsignedInteger()->references('users.id');

I'm not expert on databases. But, on this first version we can consider that FK's will always be unsignedInteger() type (i have never used other type than this). So, this statement can be suppressed by adding it on "field types" by default when using references().

Field::make('user_id')->required()->unsignedInteger()->references('users.id')->label("User");
Field::make('user_id')->required()->references('users.id')->label("User");

Can you handle it?

[deiucanta]

The issue here might be if the user id is not unsignedInteger. It can be string, integer (with negative values), unsignedBigInteger, etc. How to handle that?

I created REST APIs in Laravel that used UUIDs for the primary key. I also can imagine someone having big tables and using bigIncrements instead of increments.

[deiucanta]

The diff algorithm is just a proof of concept and I'd rather refactor it than patch it to make foreign keys work. Especially for dropping them.

We also didn't touch the requirement of having indexes on multiple fields. That would also impact the diff algorithm, the migration generation, and even the API for field definition.

I'd say we should address all these issues together to get the best outcome.

[robsontenorio]

Ok, you got me. Em sáb, 1 de set de 2018 às 10:31, Andrei Canta <notifications@github.com> escreveu:

The issue here might be if the user id is not unsignedInteger. It can be string, integer (with negative values), unsignedBigInteger, etc. How to handle that? I created REST APIs in Laravel that used UUIDs for the primary key. I also can imagine someone having big tables and using bigIncrements instead of increments. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHQq7NxknRrGZJCW_iJ9GViMqKmYNatks5uWowEgaJpZM4WOuTK> .

-- — Robson Tenório