heya, Sorry to reply to myself, but I seem to have the split worked out, using string syntax as suggested by Daniel, as you would for a FK to a model not yet defined (http://docs.djangoproject.com/en/dev/ref/models/ fields/#foreignkey).
It seems to work now, however, it is a bit messier than directly referring to models by their name alone. So the design question from my previous message still stands - is this a candidate for splitting up across apps like this, or am I better off going for a single app, and splitting up the models.py within there? Or any other techniques you might recommend, to make the design more logical and the models.py less unwieldly/large? Cheers, Victor On Nov 30, 10:44 pm, bruno desthuilliers <bruno.desthuilli...@gmail.com> wrote: > On 30 nov, 07:01, Victor Hooi <victorh...@gmail.com> wrote: > > > Hi, > > > I had an application with a fairly large models.py file, which I split > > up into separate apps to make it easier to manage. > > This won't address your problem but FWIW, you don't have to use > separate apps just to split a models.py file - you can turn it into a > models package, with the package's __init__.py used as a "facade" for > the submodules (usual pythonic solution). > > But anyway: > > > Two of the apps are called "conferences" and "people", each with their > > own models.py. > > > These two are fairly tightly entwined, they each refer to each other. > > If both models really depend that much on each other then they ought > te live in a same module. Or perhaps there's room for improvement in > your design but you don't give enough context. > > (snip typical circular deps symptom) > > > I'm not sure why this is happening - from the looks of it, it's > > opening up conferences/models.py, then importing people.models.Person > > from there, which inside of that tries to import Conference > > In Python almost everything happens at runtime. The import, class and > def statements are executable statements, and they are executed - with > every other top-level statement - when the module is first loaded. > > > Or is there a better way of creating multiple apps that all share > > models? > > Put the interdependent models in a same app. The you can have other > apps using these models too as long as there's no circular > dependencies. > > A Django app doesn't have to define models or views or urls or > whatever - you can have one app with models, and another vwith views > and forms and whatnot depending on the first app's models. > > > The main reason I split it up was for logically separating all > > the different models, they still all need to import/relate to each > > other. > > Once again: if your models are tightly coupled, they ought to live in > a same module. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
