Versioned migrations do not work with GlobalUniqueID

[masseelch]

Suppose trying to generate versioned migrations files for a global unique id enabled schema:

client.Schema.Diff(ctx, schema.WithDir(dir), schema.WithGlobalUniqueID(true))

will result into the following error:

insert into ent_types: Error 1146: Table 'migrate.ent_types' doesn't exist

• The issue is present in the latest release.
• I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

There is an error.

Expected Behavior 🤔

A new set of migration files are created that also allocate the correct ranges for the primary keys.

[masseelch]

Some context:

Ent currently supports global unique integer ids by allocating specific integer ranges for each node. When using the online migration feature, Ent inspects the connected database, plans the migration changes accordingly and applies them. While this ensures, that later added nodes get a free pk range, it renders it impossible to plan migration files in advance, since the allocated pk ranges depend on the state of the schema when migrating. This could potentially create schema drifts between different environments.

In order to support global unique id for versioned migration files as well, the pk range information have to be moved from the database instance to the schema. I propose the following solution:

1. When working with versioned migrations, next to the migration files itself Ent will create another file in the migration directory where it will store the information.
2. This file will then be used to determine the pk-ranges for each node when generating migration files

The online migration and versioned migration engines will both provide an implementation for the following interface:

// typeStore wraps methods for loading and storing pk range information for types.
type typeStore interface {
	load(context.Context) ([]string, error)
	store(context.Context, []string) error
}

[bionic-ido]

I would probably think of it as how protobuf is being used, where one needs to define the values, and when editing or deleting one, we can then reserve it so as to not shift the existing values.
I would think it to be a part of generating the schema in that sense, where one would apply the id value of each of the tables we create in order to control it.

You can also say that you don't want to make something so manual, in which case we can have it be autogenerated once, and then used the rest of the times like you suggested, in which case we'll need to have the autogenerated file committed so that subsequent uses will depend on it when generating the migrations, but I would prefer it to be separated from the autogenerated schema itself since I do not wish to have to commit it.

[giautm]

I also have an idea about moving Universel ID logic to remote service, and I purpose an interface like this:

type EntTypesStore interface {
	AllocRange(ctx context.Context, name string) (int, error)
	TypeRange(ctx context.Context, name string) (int, bool)
}

If we going to this way, I should be awesome.
More detail see: #2268

[masseelch]

[...] since I do not wish to have to commit it.

The information has to be stored somewhere. With the interface @giautm proposed (with mine as well) it is relatively easy to change the location from a file in the migration directory (schema directory) to something else like a remote service, a database or in the schema itself.

What we need to decide is what storage location to support for the offline migrations.

@bionic-ido As I understood you prefer something schema config related?

[bionic-ido]

@masseelch The way we are currently using ent is having the schema definition files be commited into our git, while having a generation script that handles the generation of all the autogenerated files out of it.
I do not wish to have to commit all of the autogenerated files, so I would much prefer the generated ent_types be placed somewhere different\be configured alongside the schema definitions, such that I would still be able to make this distinction.