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+unsubscr...@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.
