On Tue, Aug 22, 2017 at 8:37 PM, Alexander Joseph <alexander.v.jos...@gmail.com> 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...
This approach seems appealing, but personally I think it is a bad idea because the ease of introducing dependencies between apps is extremely high. Even when the apps are all tightly related to a particular project (to the extent their package name is "fooproject-some-function"), I think its better to simply develop each one as a standalone app, separate from the other apps and not requiring the other apps in order to test/develop. With this approach, you will not get unnecessarily thin apps simply because you cannot easily couple two apps together, and everything within the app should have high cohesion. Remember (or discover :) that in software engineering, high quality code is loosely coupled (it doesn't depend on many external things) and highly cohesive (the things within the module are related to each other). I would also avoid the use of subapps. First off, Django only uses the final part of the dotted import path as the app name - 'engineering.products.product1' has the same name as 'accounting.invoices.product1' (I know that doesn't exist, but...). I have a (unsubstantiated) theory that your migration woes are down to subapps. Long model files are not good, but I'd also disagree with 2SoD that getting to 5 models means a new app because of long files - what ridiculousness! If your model file is getting long, replace it with a model directory, each model in a separate module, and all of them imported in the __init__. You should split your app when it is no longer cohesive (or more accurately, when the level of cohesion is upsetting and/or slows development). 2SoD is good, but its not a holy text! Cheers Tom PS Make sure you have a sensible workflow for migrations - I'm assuming you are using some sort of version control. While you are developing your changes, you might generate a lot of temporary migrations. You do not want to apply these migrations to live, so you should squash them - either manually, using squashmigrations or by migrating the DB back to before they existed, remove them and recreate them. If you do the last one, remember to preserve any custom logic you have placed in the migration. At the end of the day, the migrations you commit are what will run on your production database, so you should ensure they do exactly what you are expecting them to do and are running in the correct order. Particularly if you have a lot of small apps, getting the dependencies right is essential. -- 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/CAFHbX1J-Oxam2oHB37ap3rY5Sio2%2BR0WGMKKpmPtT-5JMaGDHA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
