latest master raises django.core.exceptions.ImproperlyConfigured on install about django-tenant-schemas HOT 12 CLOSED

Ha! It appears the culprit is quite recent: #77

from django-tenant-schemas.

What a weird error! Did this start since we moved the signals to __init__.py?
Edit: Just saw your last message confirming it. Well, it's still a weird error. I don't understand why django would complain about this.

I'll take a careful look at this tomorrow if nobody finds a solution until then.

from django-tenant-schemas.

Alright, I tested this locally and it seems to work. Moved the receiver to listeners.py and imported it from models.py instead.

from django-tenant-schemas.

Oh and thanks for noticing so fast that it was broken! :)

from django-tenant-schemas.

Oh, you beat me to it! I was about to create a pull request with this:

MontmereLimited@20b68e0

I'm not sure which approach is better, but the bottom line is that it appears that you simply have to be careful when you import stuff in your setup.py from your project.

from django-tenant-schemas.

Oh was the whole problem this line from tenant_schemas import __version__? Yeah I think it's a cleaner solution what you did. I'd stil leave the receivers on the new file though, as I think it is a bit more intuitive this way. I don't have the habit to check the __init__.py file. The presence of listeners.py clearly indicates that we have something there.

So I'd take your changes and instead of importing the listeners from models, I'd import them from init.

Thanks so much for the help!

from django-tenant-schemas.

Ok, I'll rebase and open a pull request....

from django-tenant-schemas.

#82

from django-tenant-schemas.

People tend to name files only containing signals signals.py.

from django-tenant-schemas.

Yes walkman, I'm aware of that. Most people name it signals.py instead of listeners.py, however I find the name signals.py a bit misleading, as we're not defining any new signal, we're simply listening to them.

In fact, I've been thinking if we shouldn't simply move the code to the delete method and remove the listener. What do you guys think? The listener came before the method, so at that time we at least had an excuse to have it. But now I can't think of any reason to keep anymore.

from django-tenant-schemas.

Didn't realize this is still open - but it's resolved last I checked.

from django-tenant-schemas.

In fact, I've been thinking if we shouldn't simply move the code to the delete method and remove the listener. What do you guys think?

@bernardopires That was my first thought about this feature: #59 (comment)

You lose the benefit of Tenants not being bulk deleted but I don't think that's a big problem, as tenants only get deleted one-by-one. Even if you have to iterate through them, still not a big deal as they probably don't get deleted by hundreds.

So yes, I think moving the deleting code to TenanMixin.delete() would be ideal.

from django-tenant-schemas.