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:

U0251S9J5LP
U0251S9J5LP Posts: 22 πŸ§‘πŸ»β€πŸš€ - Cadet
edited June 2021 in Help

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

  • U0251S9J5LP
    U0251S9J5LP Posts: 22 πŸ§‘πŸ»β€πŸš€ - Cadet

    git status

  • U01LKKBK97T
    U01LKKBK97T Posts: 287 πŸ§‘πŸ»β€πŸš€ - Cadet
    edited June 2021

    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.

  • UQ958DA4U
    UQ958DA4U Posts: 232 πŸ§‘πŸ»β€πŸš€ - Cadet

    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.

  • U01LKKBK97T
    U01LKKBK97T Posts: 287 πŸ§‘πŸ»β€πŸš€ - Cadet
    edited June 2021

    Right, if you're aiming at production, you shouldn't run the demo installer at all once your db has been initialized.

  • UQ958DA4U
    UQ958DA4U Posts: 232 πŸ§‘πŸ»β€πŸš€ - Cadet

    "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?

  • U0251S9J5LP
    U0251S9J5LP Posts: 22 πŸ§‘πŸ»β€πŸš€ - Cadet

    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.

  • UQ958DA4U
    UQ958DA4U Posts: 232 πŸ§‘πŸ»β€πŸš€ - Cadet

    Agree.

  • UQ958DA4U
    UQ958DA4U Posts: 232 πŸ§‘πŸ»β€πŸš€ - Cadet

    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.

  • U01LKKBK97T
    U01LKKBK97T Posts: 287 πŸ§‘πŸ»β€πŸš€ - Cadet

    For a local setup, you could e. g. create separate importers to add your custom data on top of the default demo data.

  • U0251S9J5LP
    U0251S9J5LP Posts: 22 πŸ§‘πŸ»β€πŸš€ - Cadet

    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.

  • UQ958DA4U
    UQ958DA4U Posts: 232 πŸ§‘πŸ»β€πŸš€ - Cadet

    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.

  • U01LKKBK97T
    U01LKKBK97T Posts: 287 πŸ§‘πŸ»β€πŸš€ - Cadet

    If those generated migration files are being touched, that shouldn't matter. They shouldn't be committed to the repo, see .gitignore.