Feat: Add features like seeding and fake migrations in the cli

[rubiin]

The first case will be to insert values into the database with some useful data after a successful migration.
For reference: https://sequelize.org/master/manual/migrations.html#creating-the-first-seed

Fake migrations will be useful when a database has been created and altered manually and later you want to manage all things with migrations.
Reference: https://docs.djangoproject.com/en/3.1/topics/migrations/#initial-migrations

[B4nan]

There is already an issue for seeding: #251

You can also use CLI to import sql dumps. I don't follow what you mean by fake migrations.

[rubiin]

@B4nan I am leaving here some links for you to follow and get the idea.

https://stackoverflow.com/questions/46772762/django-migrate-fake-and-fake-initial-explained#:~:text=migrations%20run%20correctly.-,%2D%2Dfake%2Dinitial,preexisted%20the%20use%20of%20migrations.

https://dev.to/k4ml/django-migrate---fake-initial-gotchas-2fih

[B4nan]

I don't think this is possible, migrations in MikroORM are about raw SQL queries, there are no metadata available (e.g. I have no information about what the migration will do, what tables it will create/alter/drop). And I have no plans to change this, I want migrations like this, so users have absolute control and there is no magic. I have no interesting in parsing the queries to get such information (that would be a highway to hell).

[rubiin]

Its not that difficult. Suppose you have a database which which wasnt using migration. Now what you do is configure the orm for the database, generate entities using cli from that database, now generate initial migration. But since the database already exists, now what you have to do is create a migration table and insert the generated migration data only. No any alterations to the entities table needed. I managed to get a workaround for typeorm: typeorm/typeorm#6195 . Without this, you cannot use the orm migration incases like there is an existing database with some data and you only have to write a webapp

[rubiin]

It just inserts the available migration file data to migration table nothing else .

[B4nan]

It just inserts the available migration file data to migration table nothing else .

If you just started using the ORM on existing project/db, then there will be no exiting migrations that you would have to insert, that is the bit I don't understand.

[rubiin]

so how do we setup initial migrations for an existing db?

[Langstra]

You could create the entities from the existing database mikro-orm generate-entities and then generate the migrations based on the current schema diff mikro-orm migration:create.

Even though I have never tried this I think it should work. If it calculates the diff based on the current db and the entities then maybe you need to remove the database before creating the migrations. Maybe @B4nan can confirm this and close the issue or give the correct answer and then close ;)

For more questions I'd recommend using Slack or Stack overflow, Github issues are more for bugs and feature requests.
Slack channel or Stack overflow.

[B4nan]

I'd say the idea of initial migrations is valid, maybe if the opening post was more like "how do I do this", instead of "you need to implement this and that", it would be more understandable (especially when the suggestions come from FW that takes a different approach to migrations)... I really don't see a need for "fake migrations" and this is not about seeding either.

So I am fine with having a command to create the first (initial) migration, not based on diffing the current schema, but basically doing schema:create to get all the create table statements, so other users would just run migrations and end up with a working schema.

Currently with an existing project/db, you would need to distribute this initial schema dump as a separate file and import it (possibly via MikroORM CLI) first, before running the migrations.

As a workaround, one could do npx mikro-orm schema:create -d to get the initial dump and manually store it in the migrations folder, and then manually mark this migration as executed.

So my vision is basically to have npx mikro-orm migration:initial, that will do the schema:create behind the scenes (instead of using schema:update which is the current behaviour). This migration would be already marked as executed for the user who generated it. If there are already some migrations, it would throw - it would be allowed only as the very first migration to be stored.