Opened 11 years ago

Closed 11 years ago

#4146 closed (invalid)

Database Module Conflicts

Reported by: David Cramer <dcramer@…> Owned by: Adrian Holovaty
Component: Database layer (models, ORM) Version: master
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


There is an issue in the DB ORM where it's receiving conflicts between modules when doing some database calls. See

Attachments (1)

sample.txt (2.2 KB) - added by Collin Grady <cgrady@…> 11 years ago.
copy of text from dpaste, since pastebins are temporary

Download all attachments as: .zip

Change History (14)

Changed 11 years ago by Collin Grady <cgrady@…>

Attachment: sample.txt added

copy of text from dpaste, since pastebins are temporary

comment:1 Changed 11 years ago by 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 :)

comment:2 Changed 11 years ago by 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

comment:3 Changed 11 years ago by 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

comment:4 Changed 11 years ago by 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.

comment:5 Changed 11 years ago by 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.

comment:6 Changed 11 years ago by David Cramer <dcramer@…>

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

comment:7 Changed 11 years ago by David Cramer <dcramer@…>

theres 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

comment:8 Changed 11 years ago by Malcolm Tredinnick

Resolution: invalid
Status: newclosed

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 model is explicitly referring to the Item class it imported -- from 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).

comment:9 Changed 11 years ago by David Cramer <dcramer@…>

Resolution: invalid
Status: closedreopened

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 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)

comment:10 Changed 11 years ago by 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.

comment:11 Changed 11 years ago by 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

comment:12 Changed 11 years ago by 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.

comment:13 Changed 11 years ago by Malcolm Tredinnick

Resolution: invalid
Status: reopenedclosed

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

Note: See TracTickets for help on using tickets.
Back to Top