Wednesday, August 23, 2017

Re: A lot of Problems with Migrating (conceptual)

Hi,

I read in "2 Scoops of Django" that, in general, if you have more than 5 models per model file then you should think about splitting the model up into different apps, rather than having long models files.
I don't claim to be more experienced than the authors—on the contrary—and I have learnt loads from this book. However I disagree with this assertion. Five models is very few. In addition, I've found early splitting to usually be YAGNI. It causes more problems than it solves. Unless there is an obvious logical distinction of functionality right from the start, put all your models in the same app. When it grows and you see an obvious way to improve its structure, go on and refactor. Don't "refactor" from the start before you even understand your app's structure.

Regards,

Antonis

Antonis Christofides  http://djangodeployment.com

On 2017-08-22 22:37, Alexander Joseph wrote:
Thanks for all the advice.

One more question - could project structure be causing issues with migrations? I'm working on a large project and many apps in my project have several layers of "sub-apps". My structure looks something like this...



my_project/
    config/ 
    docs/
    accounting/
        invoices/
            __init__.py
            admin.py
            models.py
            urls.py
            views.py
        purchase_orders/
            __init__.py
            admin.py
            models.py
            urls.py
            views.py 
        __init__.py
        admin.py
        models.py
        urls.py
        views.py
    engineering/
        products/
            product1/
                sub_product1/
                    __init__.py
                    admin.py
                    models.py
                    urls.py
                    views.py
                __init__.py
                admin.py
                models.py
                urls.py
                views.py
            product2/
                __init__.py
                admin.py
                models.py
                urls.py
                views.py
            __init__.py
            admin.py
            models.py
            urls.py
            views.py
    requirements/
    utility/


A few things about my structure - I read in "2 Scoops of Django" that, in general, if you have more than 5 models per model file then you should think about splitting the model up into different apps, rather than having long models files. And I structured it this way so that it would be a little easier to manage - instead of having all apps under the project folder, engineering apps would belong in the engineering folder, etc.

Thanks again




On Thursday, August 17, 2017 at 11:10:01 AM UTC-6, Alexander Joseph wrote:
I'm pretty new to django and I've been having problems with makemigrations/migrate and I wonder if Im doing things right.

I'm using MySQL backend and after reading in the documentation a little it sounds like Postgresql might make migrating more painless. Usually my problems stem from changing table fields, adding new tables/models, and migrating both on my development server and my production server (PythonAnywhere)

More than once I've had to drop my database, delete all my migrations, and start over with initial migrations on the development server. This wont fly for long on production though of course .. once I actually have users and data.

I'm wondering if I should switch to postgresql or if theres any further resources that you might know of that would help me out? Thanks
--
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/d4cc32e5-c9c1-48d7-bb19-a6646800ce3d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment