--fake-initial vs --fake in Django migration?









up vote
18
down vote

favorite
2












What is the difference between --fake-initial and --fake in Django migrations? What are the dangers of using fake migrations? Anybody knows? Thank you very much to all.



I am using django 1.10










share|improve this question



























    up vote
    18
    down vote

    favorite
    2












    What is the difference between --fake-initial and --fake in Django migrations? What are the dangers of using fake migrations? Anybody knows? Thank you very much to all.



    I am using django 1.10










    share|improve this question

























      up vote
      18
      down vote

      favorite
      2









      up vote
      18
      down vote

      favorite
      2






      2





      What is the difference between --fake-initial and --fake in Django migrations? What are the dangers of using fake migrations? Anybody knows? Thank you very much to all.



      I am using django 1.10










      share|improve this question















      What is the difference between --fake-initial and --fake in Django migrations? What are the dangers of using fake migrations? Anybody knows? Thank you very much to all.



      I am using django 1.10







      django django-models django-orm django-migrations






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Jun 27 '17 at 14:20









      e4c5

      40.5k84985




      40.5k84985










      asked Mar 9 '17 at 12:39









      yooth

      10114




      10114






















          2 Answers
          2






          active

          oldest

          votes

















          up vote
          24
          down vote



          accepted










          Well the documentation is very clear about this



          --fake-initial




          Allows Django to skip an app’s initial migration if all database
          tables with the names of all models created by all CreateModel
          operations in that migration already exist. This option is intended
          for use when first running migrations against a database that
          preexisted the use of migrations. This option does not, however, check
          for matching database schema beyond matching table names




          You were asking about the risks, well here it is




          only safe to use if you are confident that your existing schema
          matches what is recorded in your initial migration.




          --fake




          Tells Django to mark the migrations as having been applied or
          unapplied, but without actually running the SQL to change your
          database schema.



          This is intended for advanced users to manipulate the current
          migration state directly if they’re manually applying changes;




          Once again risks are clearly highlighted




          be warned that using --fake runs the risk of putting the migration
          state table into a state where manual recovery will be needed to make
          migrations run correctly.




          This answer is valid not just for django versions 1.8+ but for other versions as well.



          edit Nov, 2018: I sometimes I see answers here and elsewhere that suggest that you should drop your databae. That's almost never the right thing to do. If you drop your database you loose all your data.






          share|improve this answer





























            up vote
            2
            down vote













            @e4c5 already gives an answer about this question, but I would like to add one more thing when to use --fake and --fake-initial.



            Suppose you've already a database from production and you want to use it for development and apply migration without destroying the data in that case --fake-initial will comes handy.



            This --fake-initial will force to look at your migration files, and basically skip the creation of tables that are already in your database. Do note, though that any migrations that don’t create tables but rather modify existing tables will be run.



            Conversely, If you have an existing project with migration file and you want to reset the history of existing migration then --fake is usually being used.






            share|improve this answer






















            • @heikki thanks for your edit suggestion and my answer looks way more perfect right now.
              – Shubho Shaha
              Nov 21 '17 at 5:52










            Your Answer






            StackExchange.ifUsing("editor", function ()
            StackExchange.using("externalEditor", function ()
            StackExchange.using("snippets", function ()
            StackExchange.snippets.init();
            );
            );
            , "code-snippets");

            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "1"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader:
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            ,
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );













            draft saved

            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f42695629%2ffake-initial-vs-fake-in-django-migration%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown

























            2 Answers
            2






            active

            oldest

            votes








            2 Answers
            2






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            24
            down vote



            accepted










            Well the documentation is very clear about this



            --fake-initial




            Allows Django to skip an app’s initial migration if all database
            tables with the names of all models created by all CreateModel
            operations in that migration already exist. This option is intended
            for use when first running migrations against a database that
            preexisted the use of migrations. This option does not, however, check
            for matching database schema beyond matching table names




            You were asking about the risks, well here it is




            only safe to use if you are confident that your existing schema
            matches what is recorded in your initial migration.




            --fake




            Tells Django to mark the migrations as having been applied or
            unapplied, but without actually running the SQL to change your
            database schema.



            This is intended for advanced users to manipulate the current
            migration state directly if they’re manually applying changes;




            Once again risks are clearly highlighted




            be warned that using --fake runs the risk of putting the migration
            state table into a state where manual recovery will be needed to make
            migrations run correctly.




            This answer is valid not just for django versions 1.8+ but for other versions as well.



            edit Nov, 2018: I sometimes I see answers here and elsewhere that suggest that you should drop your databae. That's almost never the right thing to do. If you drop your database you loose all your data.






            share|improve this answer


























              up vote
              24
              down vote



              accepted










              Well the documentation is very clear about this



              --fake-initial




              Allows Django to skip an app’s initial migration if all database
              tables with the names of all models created by all CreateModel
              operations in that migration already exist. This option is intended
              for use when first running migrations against a database that
              preexisted the use of migrations. This option does not, however, check
              for matching database schema beyond matching table names




              You were asking about the risks, well here it is




              only safe to use if you are confident that your existing schema
              matches what is recorded in your initial migration.




              --fake




              Tells Django to mark the migrations as having been applied or
              unapplied, but without actually running the SQL to change your
              database schema.



              This is intended for advanced users to manipulate the current
              migration state directly if they’re manually applying changes;




              Once again risks are clearly highlighted




              be warned that using --fake runs the risk of putting the migration
              state table into a state where manual recovery will be needed to make
              migrations run correctly.




              This answer is valid not just for django versions 1.8+ but for other versions as well.



              edit Nov, 2018: I sometimes I see answers here and elsewhere that suggest that you should drop your databae. That's almost never the right thing to do. If you drop your database you loose all your data.






              share|improve this answer
























                up vote
                24
                down vote



                accepted







                up vote
                24
                down vote



                accepted






                Well the documentation is very clear about this



                --fake-initial




                Allows Django to skip an app’s initial migration if all database
                tables with the names of all models created by all CreateModel
                operations in that migration already exist. This option is intended
                for use when first running migrations against a database that
                preexisted the use of migrations. This option does not, however, check
                for matching database schema beyond matching table names




                You were asking about the risks, well here it is




                only safe to use if you are confident that your existing schema
                matches what is recorded in your initial migration.




                --fake




                Tells Django to mark the migrations as having been applied or
                unapplied, but without actually running the SQL to change your
                database schema.



                This is intended for advanced users to manipulate the current
                migration state directly if they’re manually applying changes;




                Once again risks are clearly highlighted




                be warned that using --fake runs the risk of putting the migration
                state table into a state where manual recovery will be needed to make
                migrations run correctly.




                This answer is valid not just for django versions 1.8+ but for other versions as well.



                edit Nov, 2018: I sometimes I see answers here and elsewhere that suggest that you should drop your databae. That's almost never the right thing to do. If you drop your database you loose all your data.






                share|improve this answer














                Well the documentation is very clear about this



                --fake-initial




                Allows Django to skip an app’s initial migration if all database
                tables with the names of all models created by all CreateModel
                operations in that migration already exist. This option is intended
                for use when first running migrations against a database that
                preexisted the use of migrations. This option does not, however, check
                for matching database schema beyond matching table names




                You were asking about the risks, well here it is




                only safe to use if you are confident that your existing schema
                matches what is recorded in your initial migration.




                --fake




                Tells Django to mark the migrations as having been applied or
                unapplied, but without actually running the SQL to change your
                database schema.



                This is intended for advanced users to manipulate the current
                migration state directly if they’re manually applying changes;




                Once again risks are clearly highlighted




                be warned that using --fake runs the risk of putting the migration
                state table into a state where manual recovery will be needed to make
                migrations run correctly.




                This answer is valid not just for django versions 1.8+ but for other versions as well.



                edit Nov, 2018: I sometimes I see answers here and elsewhere that suggest that you should drop your databae. That's almost never the right thing to do. If you drop your database you loose all your data.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Nov 11 at 13:06

























                answered Mar 9 '17 at 12:42









                e4c5

                40.5k84985




                40.5k84985






















                    up vote
                    2
                    down vote













                    @e4c5 already gives an answer about this question, but I would like to add one more thing when to use --fake and --fake-initial.



                    Suppose you've already a database from production and you want to use it for development and apply migration without destroying the data in that case --fake-initial will comes handy.



                    This --fake-initial will force to look at your migration files, and basically skip the creation of tables that are already in your database. Do note, though that any migrations that don’t create tables but rather modify existing tables will be run.



                    Conversely, If you have an existing project with migration file and you want to reset the history of existing migration then --fake is usually being used.






                    share|improve this answer






















                    • @heikki thanks for your edit suggestion and my answer looks way more perfect right now.
                      – Shubho Shaha
                      Nov 21 '17 at 5:52














                    up vote
                    2
                    down vote













                    @e4c5 already gives an answer about this question, but I would like to add one more thing when to use --fake and --fake-initial.



                    Suppose you've already a database from production and you want to use it for development and apply migration without destroying the data in that case --fake-initial will comes handy.



                    This --fake-initial will force to look at your migration files, and basically skip the creation of tables that are already in your database. Do note, though that any migrations that don’t create tables but rather modify existing tables will be run.



                    Conversely, If you have an existing project with migration file and you want to reset the history of existing migration then --fake is usually being used.






                    share|improve this answer






















                    • @heikki thanks for your edit suggestion and my answer looks way more perfect right now.
                      – Shubho Shaha
                      Nov 21 '17 at 5:52












                    up vote
                    2
                    down vote










                    up vote
                    2
                    down vote









                    @e4c5 already gives an answer about this question, but I would like to add one more thing when to use --fake and --fake-initial.



                    Suppose you've already a database from production and you want to use it for development and apply migration without destroying the data in that case --fake-initial will comes handy.



                    This --fake-initial will force to look at your migration files, and basically skip the creation of tables that are already in your database. Do note, though that any migrations that don’t create tables but rather modify existing tables will be run.



                    Conversely, If you have an existing project with migration file and you want to reset the history of existing migration then --fake is usually being used.






                    share|improve this answer














                    @e4c5 already gives an answer about this question, but I would like to add one more thing when to use --fake and --fake-initial.



                    Suppose you've already a database from production and you want to use it for development and apply migration without destroying the data in that case --fake-initial will comes handy.



                    This --fake-initial will force to look at your migration files, and basically skip the creation of tables that are already in your database. Do note, though that any migrations that don’t create tables but rather modify existing tables will be run.



                    Conversely, If you have an existing project with migration file and you want to reset the history of existing migration then --fake is usually being used.







                    share|improve this answer














                    share|improve this answer



                    share|improve this answer








                    edited Nov 20 '17 at 21:49









                    Heikki

                    1,2651017




                    1,2651017










                    answered Nov 20 '17 at 19:55









                    Shubho Shaha

                    539513




                    539513











                    • @heikki thanks for your edit suggestion and my answer looks way more perfect right now.
                      – Shubho Shaha
                      Nov 21 '17 at 5:52
















                    • @heikki thanks for your edit suggestion and my answer looks way more perfect right now.
                      – Shubho Shaha
                      Nov 21 '17 at 5:52















                    @heikki thanks for your edit suggestion and my answer looks way more perfect right now.
                    – Shubho Shaha
                    Nov 21 '17 at 5:52




                    @heikki thanks for your edit suggestion and my answer looks way more perfect right now.
                    – Shubho Shaha
                    Nov 21 '17 at 5:52

















                    draft saved

                    draft discarded
















































                    Thanks for contributing an answer to Stack Overflow!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid


                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.

                    To learn more, see our tips on writing great answers.





                    Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                    Please pay close attention to the following guidance:


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid


                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.

                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f42695629%2ffake-initial-vs-fake-in-django-migration%23new-answer', 'question_page');

                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    這個網誌中的熱門文章

                    How to read a connectionString WITH PROVIDER in .NET Core?

                    Node.js Script on GitHub Pages or Amazon S3

                    Museum of Modern and Contemporary Art of Trento and Rovereto