Re: A lot of Problems with Migrating (conceptual)

OK, so I started over using postrgresql and so far I have one app named 'accounts' - to hold user models, registration, etc. I tried to migrate and got the following error which looks a lot like some of the errors I was getting before..

(business_management) C:\Python36\Projects\business_management>python manage.py migrate --settings=config.settings.local

Traceback (most recent call last):

  File "manage.py", line 22, in <module>

    execute_from_command_line(sys.argv)

  File "C:\Users\Alexander\Envs\business_management\lib\site-packages\django\core\management\__init__.py", line 363, in execute_from_command_line

    utility.execute()

  File "C:\Users\Alexander\Envs\business_management\lib\site-packages\django\core\management\__init__.py", line 355, in execute

    self.fetch_command(subcommand).run_from_argv(self.argv)

  File "C:\Users\Alexander\Envs\business_management\lib\site-packages\django\core\management\base.py", line 283, in run_from_argv

    self.execute(*args, **cmd_options)

  File "C:\Users\Alexander\Envs\business_management\lib\site-packages\django\core\management\base.py", line 330, in execute

    output = self.handle(*args, **options)

  File "C:\Users\Alexander\Envs\business_management\lib\site-packages\django\core\management\commands\migrate.py", line 86, in handle

    executor.loader.check_consistent_history(connection)

  File "C:\Users\Alexander\Envs\business_management\lib\site-packages\django\db\migrations\loader.py", line 298, in check_consistent_history

    connection.alias,

django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency accounts.0001_initial on database 'default'.

let me know if you need anymore info to help me out with this. Thanks in advance

On Friday, August 25, 2017 at 12:25:00 PM UTC-6, Alexander Joseph wrote:

Awesome, thanks James, thats exactly what I'm looking for. I'll try layout 1 first as you suggest

On Wednesday, August 23, 2017 at 7:49:05 PM UTC-6, James Schneider wrote:

On Wed, Aug 23, 2017 at 4:40 PM, Alexander Joseph <alexander...@gmail.com> wrote:

One more question - is there a way to put apps in folders/sub-folders instead of creating sub-apps/modules? I just want to keep things easier to navigate on the development side. I will eventually have about 20 sub-apps in the 'Engineering' app alone.

Even if I could just group all the engineering sub-apps i have now under an engineering folder without any further hierarchy that would help as there will also be HR, financial apps, administration apps, etc.

Thanks again

Technically you can go as deep as you'd like. You can use the module strategy to emulate a Django 'app' without all the registration fuss. A couple abbreviated examples:

# 1. Group resources and references by object type

project/

    engineering/

        __init__.py

        models/

            __init__.py

             widgets.py

             gadgets.py

             product1.py

             product2.py

        views/

            __init__.py

            product1.py

            product2.py

     # etc.

All of the models for engineering would be grouped in a single 'models' module. Imports would look like 'from engineering.models.widgets import WonderWidget'

The engineering/models/__init__.py file would contain lines like 'from .widgets import *' for all of your files that contain models.

# 2. Group by business segment or workflow

project/

    engineering/

        __init__.py

        models.py

        product1/

            __init__.py

            models.py

            views.py

            urls.py

        product2/

            __init__.py

            models.py

            views.py

            urls.py

     # etc.

                

In this case, you're replicating the structure of an 'app' without creating one by Django's definition. The engineering/models.py file would then contain imports like 'from .product1.models import *' in order to get the model auto-discovery to work correctly. 

I'm under the impression that most developers use layout #1, but a large project might work better with #2 if there aren't a lot of cross-dependencies. 

Note that using Python modules rather than real Django apps will also keep your settings.INSTALLED_APPS list minimized. With as many 'apps' as you were originally talking about, that list could be dozens or hundreds of items long.

IMHO I would start with #1 and see how it works for you. It could be the generalized term 'product' that you're using, but to me, a product would not trigger a new 'app' for me, just extra model/view/url/etc. files, especially given how often products change or are added/removed. In that case, #2 might work better since all of the related code is within a single sub-folder (but all the references to that code aren't, so there is still work to be done). YMMV

-James

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/865261bf-230e-4a1d-b8d5-dd7275fa8c22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.