How to unregister model?

[Tomasz Zieliński]

Is there a way to unregister model from being seen by Django model
manager?
I have some unmanaged models that are wrappers around read-only
database views
and also have foreign keys to 'real' models.

Now, when I'm trying to delete instance of 'real' model that is
referenced by unmanaged model,
I'm getting OperationalErrors as Django tries to perform cascade
delete.

As a solution, I'd like to unregister my unmanaged models
before .delete(),
and re-registering them after, but I don't know how to do it.

--
Tomasz Zielinski
http://pyconsultant.eu

[Tim Valenta]

If you're not doing anything fancy with AdminSite objects (ie, you're
only using the default admin site), then do this:

# assuming you've already done: from django.contrib import admin
admin.site.unregister(MyModel)

Note that it's exactly the opposite of the normal "admin.site.register
()" method, except that it only ever takes the one argument, not two.

I do this for changing the default User model admin. I unregister it,
alter the UserAdmin provided in Django, and then re-register it with
my own.

Tim

On Nov 24, 1:54 pm, Tomasz Zieliński

[Tim Valenta]

Sorry for double-post.

Additionally, you might experiment with the Meta class attribute,
"abstract = True" on your wrapper models. It makes Django ignore the
model when it does database table creation. That way, your wrapper
acts more like a true Python inheritance object, where you simply get
the benefits of inherited methods and fields, without the wrapper
creating its own lonely table without any data.

Not sure if it fits your situation, but it's good to know about. It
seems like you're having to worry a bit too much about the extra
models. There are all kinds of uses once you figure out how to use
it.

Here's the docs on it:

http://docs.djangoproject.com/en/dev/topics/db/models/#id6

On Nov 24, 2:15 pm, Tim Valenta <tonightslasts...@gmail.com> wrote:
> If you're not doing anything fancy with AdminSite objects (ie, you're
> only using the default admin site), then do this:
>
> # assuming you've already done: from django.contrib import admin
> admin.site.unregister(MyModel)
>
> Note that it's exactly the opposite of the normal "admin.site.register
> ()" method, except that it only ever takes the one argument, not two.
>
> I do this for changing the default User model admin. I unregister it,
> alter the UserAdmin provided in Django, and then re-register it with
> my own.
>
> Tim
>

> On Nov 24, 1:54 pm, Tomasz Zieliñski

[Tomasz Zieliński]

On 24 Lis, 22:15, Tim Valenta <tonightslasts...@gmail.com> wrote:
> If you're not doing anything fancy with AdminSite objects (ie, you're
> only using the default admin site), then do this:
>
> # assuming you've already done: from django.contrib import admin
> admin.site.unregister(MyModel)
>

The 'unregister' word seems to have been misleading, as I wasn't
referring
to admin panel at all :)

I want my unmanaged models to literally disappear from Django sight,
and then re-appear on demand.

[Tomasz Zieliński]

On 24 Lis, 22:18, Tim Valenta <tonightslasts...@gmail.com> wrote:
> Sorry for double-post.
>
> Additionally, you might experiment with the Meta class attribute,
> "abstract = True" on your wrapper models.  

Thank you, I know about 'abstract' and I am using but unfortunately
it doesn't help me much. What I need is the ability to somehow hide
for a while non-abstract unmanaged models.

[Tim Valenta]

> I want my unmanaged models to literally disappear from Django sight,
> and then re-appear on demand.

That sounds rather hack-ish... I'm not sure Django can do that
exactly. I'm not familiar with the situation, exactly, so I'm unsure
of what you might be able to do differently.

Apologies.

Tim

On Nov 24, 2:18 pm, Tomasz Zieliński

[Tomasz Zieliński]

On 24 Lis, 22:42, Tim Valenta <tonightslasts...@gmail.com> wrote:
> > I want my unmanaged models to literally disappear from Django sight,
> > and then re-appear on demand.
>
> That sounds rather hack-ish... I'm not sure Django can do that
> exactly.  I'm not familiar with the situation, exactly, so I'm unsure
> of what you might be able to do differently.
>

I'm suffering from something similar to this:

http://code.djangoproject.com/ticket/10829

- and I prefer to avoid hacking Django core, resorting to raw SQL etc.
I only I could hide those unmanaged models, things would be smooth
again,
even though it's not the cleanest solution.

[Tim Valenta]

> http://code.djangoproject.com/ticket/10829

Seeing as how it was last updated over a month ago, you might be best
off by downloading his patch and applying it, because there may not be
a solution very quickly. Development for version 1.2 is going on
right now, and they're focusing on brand-new features at the moment.
Bug fixes and such tweaks (which I think this will be categorized as)
won't start getting attention until January.

If you've got an SVN checkout of Django, you can apply the patch with
some simple SVN commands (easily Google'd). Just look for something
about applying a patch, specifically with that vocabulary.

If you've got a frozen downloaded version, you could open up the
".diff" patch in a text editor and figure out which file it's
patching, and add any lines with a "+" in front of it, and remove any
with a "-" in front of it.

I'm afraid there won't be a core update right away, and it sounds like
you're in need of one. Unless someone more knowledgeable with the
Database layer can help out, I'm unsure of what else you might be able
to do.

On Nov 24, 3:02 pm, Tomasz Zieliński

[Tomasz Zieliński]

That patch is a hack that requires modifying live instance of Django,
moreover I don't know what is influenced by it as I'm not that
familiar
with inner workings of model layer, so using it would be troublesome
for me.

So it seems that I have to write custom delete()s, using raw SQL..

[Hanne Moa]

2009/11/25 Tomasz Zieliński <tomasz.z...@pyconsultant.eu>:

> That patch is a hack that requires modifying live instance of Django,
> moreover I don't know what is influenced by it as I'm not that
> familiar
> with inner workings of model layer, so using it would be troublesome
> for me.
>
> So it seems that I have to write custom delete()s, using raw SQL..

There's a lot of tickets about the problems caused by implicit
cascaded deletes. Your use-case I think is new however (though, I've
been planning to use views myself...). You might want to collect all
of the "delete cascades" tickets and add your use-case to the most
relevant of them, mark all the rest as duplicates then tell the
developer-list.

Fixing this *is* on the roadmap for 1.2:
http://code.djangoproject.com/wiki/Version1.2Features
but: it has the lowest priority so there's room for you to step in.

Now for database views, what we really need is a way to mark that a
model is read-only/should never be updated in any way from/via django.


HM