Database Module Conflicts

[David Cramer <dcramer@…>]

There is an issue in the DB ORM where it's receiving conflicts between modules when doing some database calls. See ​http://dpaste.com/hold/8999/

[Collin Grady <cgrady@…>]

copy of text from dpaste, since pastebins are temporary

[Collin Grady <cgrady@…>]

Forgive me if I'm just missing it, but where exactly is the problem? You're not giving much in the way of details :)

[David Cramer <dcramer@…>]

I have two models in the same subdirectories (inside of different base directories) and somehow the environment is pulling one over the other

[Malcolm Tredinnick]

We really need a better bug report here. I have no idea what problem is being reported. That paste example doesn't explain a number of things, as well as exhibiting some bad practices that may not ever be able to work (doing a query on the !Equpiment class as the !Import class is being defined is dubious).

Instead of asking us to reverse-engineer the problem from a fragment, please detail clearly:

1. What is actually going wrong
2. What you would expect to happen instead

[David Cramer <dcramer@…>]

Did you look at the nice cut up chunk of code in dpaste? There are 2 models with the same name in different apps. They are conflicting on the import and the one which *should* be used as the relational db isn't, the other module is.

[Collin Grady <cgrady@…>]

You only have one Equipment model and one Item model in the paste, so there doesn't seem to be any sort of conflict possible - nor do you indicate which model is supposedly giving trouble.

[David Cramer <dcramer@…>]

The equipment module is importing from a different location then the module I pasted. The path names are provided.

[David Cramer <dcramer@…>]

theres cursesite.portals.wow.database.models and cursesite.portals.lotro.database.models, both contain an Item() class, lotro is listed in INSTALLED_APPS, wow isnt, it should be referencing wow in the Equipment model but its referencing lotro

[Malcolm Tredinnick]

I think I see what you are talking about now (and yes, surprisingly enough I did read the paste fragment before posting my request for clarification). It wasn't clear until you explained it that that fragment was actually two or three different files.

This is no bug here.

The cursesite.portals.wow.profiles.models.Equipment model is explicitly referring to the Item class it imported -- from cursesite.portals.wow.profiles.models. If you want to refer to the other Item class, you should import that instead. Since you are referring to things by reference, there is no ambiguity possible and no reason to check INSTALLED_APPS (which we don't do). In fact, this is necessary behaviour because otherwise you wouldn't be able to create foreign keys to both Item classes from the same model (which you can do at the moment by importing both of them and referring to them by reference).

[David Cramer <dcramer@…>]

The problem is its *not* referring to that item class. It's somehow joining with the other item class which is loaded in INSTALLED_APPS. It should be referencing cursesite.portals.wow.database.models.Item but it's referencing cursesite.portals.lotro.database.models.Item when I'm using the config which has it loaded. (it works fine on other site's which dont use the lotro app)

[Malcolm Tredinnick]

Okay, now I understand.

Does the problem go away if you put the "wow" class in INSTALLED_APPS? A lot of the query construction mechanics for related items use the internal app_cache which is generated from INSTALLED_APPS.

If this goes away when wow is in INSTALLED_APPS then it's not a bug, because it's not really possible to get related objects working without the app_cache. If it's still there when the app is in INSTALLED_APPS, we have some other problem at work.

[David Cramer <dcramer@…>]

I'll run up some new unit tests as I moved the app to stop the conflicts for now, but when I've used this stuff before I'm able to query the related objects when wow isnt in INSTALLED_APPS

[Malcolm Tredinnick]

David, even if this used to work, it was purely by accident and it's not something you should rely on.

If you are wanting Django's ORM to work with an application, it should be in the INSTALLED_APPS list. That isn't an unreasonable requirement and it's what saves you from having to annotate both end of relation fields, for example. As I mentioned above, there is a lot of code that relies on using the app_cache to work between models and it would be quite a restriction on future development if we also needed to make sure things worked for the very rare cases where something isn't in INSTALLED_APPS (some things won't work at all, even now, for apps not in that list).

So this ticket is only a bug if it continues to occur when both apps are in the installed list.

[Malcolm Tredinnick]

Closing, as the originally reported problem isn't a Django bug. Please reopen if the problem reoccurs with both apps in INSTALLED_APPS.