Thanks James, and thanks for your post on my other thread about structure.
I agree I need to get more into conceptual introductory material. I think I
as you suggested. From what Tom said it sounds like that could be a lot of
where my migration issues are coming from. I've seen a lot of dependency
related errors when trying to run migrations.
Thanks all for the ongoing advice. I'll try to keep this thread updated on
Post by James Schneider
On Tue, Aug 22, 2017 at 12:37 PM, Alexander Joseph <
Post by Alexander Joseph
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...
Possibly, especially if you're introducing any import loops. It's easy to
do. Trying to get the autodiscover mechanism for models to run through
nested apps can also be fun.
A few things about my structure - I read in "2 Scoops of Django" that, in
Post by Alexander Joseph
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.
It depends. Your structure will likely change throughout the life of your
project. Start with what you have now and mold accordingly. Loose coupling
is key, though, to make it easier to move things around.
Like I mentioned in your other thread, you need to redefine what you are
considering an 'app'. Your current definition is way too specific/narrow,
which is why you are ending up with so many. Almost certainly each product
does not need its own app. That's not to say you shouldn't break them
apart. I'm saying keep your 'apps' generalized (ie engineering, accounting,
etc.) and break up the models into importable Python modules with a
sensible structure. Using modules will alleviate much of the pain of the
app and model discovery process using the pattern I described in the other
thread. It also provides a mechanism for loose coupling, and keeps your
models in separate files/folders using any structure you'd like. Reducing
the number of apps also reduces the number of files present in your
project, since you only need a single apps.py for a larger app, rather than
managing 20 apps.py files for 20 smaller apps.
2SoD is an excellent resource, and in no way to do I claim to have a
modicum of the knowledge and experience that the authors do. I don't even
program for a living. I have a copy for 1.8. You will notice in the book
that they do not have separate apps for an ice cream cone vs. ice cream
sandwiches vs. toppings, even though these may be analogous to your
product_1, product_2, etc. It's hard to tell though, because I'm assuming
you generalized your structure, so I don't know if you are talking about
different ice cream-based treat types, or cars vs. rocket ships. The latter
would likely use separate apps because there would be little overlapping
workflows and logic, along with multiple models associated with each.
I'd recommend looking in to some introductory material on database
normalization, not so much for the mechanics, but rather more conceptually.
The way you would break things apart for normalization often coincides
neatly with the way you should break apart apps (and builds your model list
for you), somewhere around the 2nd normal form. Again, your structure will
likely change as you go, so use the loose coupling via the __init__.py
module imports as I've shown, and that should help with the transition.
You received this message because you are subscribed to a topic in the
Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/
To unsubscribe from this group and all its topics, send an email to
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/
For more options, visit https://groups.google.com/d/optout.