Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Database migrations #778

Open
lsv opened this issue Apr 5, 2018 · 11 comments
Open

Database migrations #778

lsv opened this issue Apr 5, 2018 · 11 comments
Labels

Comments

@lsv
Copy link

lsv commented Apr 5, 2018

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

@lsv lsv changed the title Migrations Database migrations Apr 5, 2018
@bocharsky-bw
Copy link
Contributor

bocharsky-bw commented Apr 6, 2018

Probably because best practice - does not use migrations in production

Sorry, I wrote something weird

@jkufner
Copy link
Contributor

jkufner commented Apr 6, 2018

@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
Copy link
Member

stof commented Apr 6, 2018

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

@lsv
Copy link
Author

lsv commented Apr 6, 2018

@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
Copy link
Contributor

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

Of course, migrations sound totally great for production 👍

@lsv lsv mentioned this issue Apr 12, 2018
@yceruto
Copy link
Member

yceruto commented Apr 12, 2018

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
Copy link
Author

lsv commented Apr 13, 2018

@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
Copy link
Member

yceruto commented Apr 13, 2018

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
Copy link
Author

lsv commented Apr 13, 2018

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
Copy link
Member

yceruto commented Apr 13, 2018

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

@lsv
Copy link
Author

lsv commented Apr 13, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants