Database migrations

[lsv]

Why not use migrations to create the database, instead of relying on sqlite, so other RDBMS could be used

I will gladly make real migrations to use if needed

[bocharsky-bw]

Probably because best practice - does not use migrations in production

Sorry, I wrote something weird

[jkufner]

@bocharsky-bw Not using migrations is not best practice.

@lsv There are no migrations because nobody made them. One important thing discussed earlier is to make demo work without running migrations or doing anything except composer install && ./bin/console server:run.

[stof]

@bocharsky-bw using migrations for production instead of using doctrine:schema:update is precisely the best practice.

[lsv]

@bocharsky-bw well, its actually better using migration than fixtures in production imo And yes, migrations can also have fixtures

@jkufner This will still work, due to the sqlite database is provided, though it would be lovely to also try symfony demo on other databases like postgresql, mysql, mariadb, mssql.

And I also think, it will give "best practice" on how not to rely on a single database manufactur

[bocharsky-bw]

Sorry guys, somehow I was thinking about "fixtures" instead of "migrations".

Of course, migrations sound totally great for production 👍

[yceruto]

Initial migration for multiple DBMS sound weird to me with DoctrineMigrationsBundle that generates pure SQL statements (which can be different through DBMS) according to the current driver.

I don't know if something similar to Django migrations is provided for another Symfony bundle, but IMHO starting with doctrine:schema:create + doctrine:fixtures:load do the full job whatever environment that is.

[lsv]

@yceruto doctrine:fixtures:load is a "destructive" command, and it will reset your database completely, and therefor it should not be available in production mode. (or append data, but this will in my mind just mess up a production database anyway)

And as this is a demo, I think it should enforce best practices, and as DoctrineFixtures only installs in dev and test mode by default (by its flex recipe)

And true, DoctrineMigrations it will create pure SQL statements, which will be different pr database provider, and therefor this demo will also work on mysql, postgres etc where now it only works with sqlite (which is not the best performer).

I like to think that somebody uses this demo as a base for there system, and will develop it into something bigger, and "help" them so they also can use other DBMS will be great, in my mind.

[yceruto]

doctrine:fixtures:load is a "destructive" command, and it will reset your database completely, and therefor it should not be available in production mode.

Yes, I mean from scratch. Currently we can run doctrine:fixtures:load --env=dev in production to populate the initial data. An example of workflow in production server for project initialization could be:

1. install vendor with --dev reqs
2. doctrine:schema:create + doctrine:fixtures:load --env=dev
3. remove cache and install vendor without --dev reqs

[lsv]

That depends on what "demo" should be.

Is is just a show case of random data and clicking around (front wise), or is it to show best practice from symfony, on "how to code things" (code wise). Maybe I'm much more interested in the actually code than the frontend :)

Actually if you are installing from scratch it should not have any data at all - Only for the heroku it should have data. Now I dont know what you can do behind the scene to deploy on heroku (commands).

But still in my PR I have kept the blog.sqlite (which already have fixtures installed) so no commands are needed to see the demo. (but its now possible to also use other DBMS)

[yceruto]

What is the best practice to populate the initial data on production?

[lsv]

In my mind its using migrations. (though in this demo) its not actually data, but more like test data.

Like in a fresh wordpress installation you would not start with 50 blog posts, but maybe just one "Hello World" post - And this "Hello World" post I would add in the migration.

But for dev/test environment you will also have the initial migration, but are able to run fixtures