Code

Opened 7 years ago

Closed 7 years ago

#4146 closed (invalid)

Database Module Conflicts

Reported by: David Cramer <dcramer@…> Owned by: adrian
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:

Description

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/

Attachments (1)

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

Download all attachments as: .zip

Change History (14)

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

copy of text from dpaste, since pastebins are temporary

comment:1 Changed 7 years ago by Collin Grady <cgrady@…>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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 7 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 7 years ago by mtredinnick

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 7 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 7 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 7 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 7 years ago by 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

comment:8 Changed 7 years ago by mtredinnick

  • Resolution set to invalid
  • Status changed from new to closed

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

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

  • Resolution invalid deleted
  • Status changed from closed to reopened

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)

comment:10 Changed 7 years ago by mtredinnick

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 7 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 7 years ago by mtredinnick

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 7 years ago by mtredinnick

  • Resolution set to invalid
  • Status changed from reopened to closed

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.