What are the Slack Archives?
Itβs a history of our time together in the Slack Community! Thereβs a ton of knowledge in here, so feel free to search through the archives for a possible answer to your question.
Because this space is not active, you wonβt be able to create a new post or comment here. If you have a question or want to start a discussion about something, head over to our categories and pick one to post in! You can always refer back to a post from Slack Archives if needed; just copy the link to use it as a reference..
the install recipe of the demo store deletes the migrations: ```delete-migration-files:
the install recipe of the demo store deletes the migrations:
delete-migration-files: command: "vendor/bin/console propel:migration:delete"
later on new migrations will be created (propel:diff). any idea why not the existing migrations will be executed? migration files which are checked in into repository should not be deleted, right?
Comments
-
git status
0 -
Running the demo installer will resetup your db from scratch. Hence, there's no data that needs to be migrated, so migrations will be reset, too.
0 -
Yeah you simply need to get rid of that item in the recipe and then start fresh with a committed initial migration and a propel:migrate instead of the diffing stuff if you want a more production ready scenario.
0 -
Right, if you're aiming at production, you shouldn't run the demo installer at all once your db has been initialized.
0 -
"the demo installer" is a rather broad term as it just refers to all the recipes for the demo shop. or has that changed in the mean time?
0 -
no, iβm aiming for local installβ¦ mosts projects i was working with use the demo shop as a basement and build there changes on top of it. didnβt know itβs necessary to adjust development.yml. maybe it would be better to remove that stuff for the demo shop too and instead check in an initial migration.
0 -
Agree.
0 -
Spryker probably does it that way so you can move quicker without having to understand migrations for quick throwaway stuff so that playing around is easier on the user.
0 -
For a local setup, you could e. g. create separate importers to add your custom data on top of the default demo data.
0 -
for database structure we like to keep using migrations, thatβs what they are there for i guess - for data we already use some importers. we just donβt want to have the install script touch files that are checked in the repository. every change to these files should be done by our developers on purpose.
0 -
Yep. It's also how we've built successful shops. Custom importers and switching to a migration workflow prior go live and committing migration files, then just running migrate on the systems.
0 -
If those generated migration files are being touched, that shouldn't matter. They shouldn't be committed to the repo, see .gitignore.
0
Categories
- All Categories
- 42 Getting Started & Guidelines
- 7 Getting Started in the Community
- 8 Additional Resources
- 7 Community Ideas and Feedback
- 76 Spryker News
- 929 Developer Corner
- 787 Spryker Development
- 89 Spryker Dev Environment
- 362 Spryker Releases
- 3 Oryx frontend framework
- 35 Propel ORM
- 68 Community Projects
- 3 Community Ideation Board
- 30 Hackathon
- 3 PHP Bridge
- 6 Gacela Project
- 26 Job Opportunities
- 3.2K π Slack Archives
- 116 Academy
- 5 Business Users
- 370 Docker
- 551 Slack General
- 2K Help
- 75 Knowledge Sharing
- 6 Random Stuff
- 4 Code Testing
- 32 Product & Business Questions
- 70 Spryker Safari Questions
- 50 Random