Feature proposal: selection of views and tables for inspectdb

[José Tomás Tocino]

Hi there.

I have an Oracle database that I access from Django with a user with limited privileges that can access some special views the DBA has set up for me. I wanted to use inspectdb to automatically generate the models for those views, but it didn't work.

The problem is that the SQL statement that Django uses to fetch the tables and views [1] for the current user does not properly return the views I need because the user does not own them, and USER_VIEWS only returns those VIEWS owned by the user. Not owning a table or a view should not be an obstacle for automatically generating a model, so my proposal is to extend the inspectdb to allow selecting what tables and views should be considered for inspection. This would enable the inspection of tables and/or views that the user does not own, as long as their name is known.

It would be very easy to do, just add an optional positional argument to the inspectdb commands for the names of the tables/views and, if it's available, just inspect those tables/views instead of those returned by the introspection service.

Here's a patch of a possible solution:

--- django/django/core/management/commands/inspectdb.py 2015-10-31 20:50:57.401113597 +0100

+++ /home/jose/.virtualenvs/ori2/lib/python3.4/site-packages/django/core/management/commands/inspectdb.py 2015-10-31 20:52:26.241112474 +0100

@@ -19,6 +19,8 @@

         parser.add_argument('--database', action='store', dest='database',

             default=DEFAULT_DB_ALIAS, help='Nominates a database to '

             'introspect. Defaults to using the "default" database.')

+        parser.add_argument('table', action='store', nargs='*', type=str,

+                            help='Selects what tables or views should be introspected')

 

     def handle(self, **options):

         try:

@@ -50,7 +51,12 @@

             yield ''

             yield 'from %s import models' % self.db_module

             known_models = []

-            for table_name in connection.introspection.table_names(cursor):

+            if options['table']:

+                tables_to_introspect = options['table']

+            else:

+                tables_to_introspect = connection.introspection.table_names(cursor)

+

+            for table_name in tables_to_introspect:

                 if table_name_filter is not None and callable(table_name_filter):

                     if not table_name_filter(table_name):

                         continue

Regards

P.S.: sorry if I messed up any rule of the contribution guidelines, I'm not used to contributing to large open source projects.

[1] https://github.com/django/django/blob/master/django/db/backends/oracle/introspection.py#L54

[Josh Smeaton]

Hi José,

Can I just clarify the problem for a second.

Are you saying that inspectdb isn't returning output for tables owned by a separate user but visible to the django User? If so, there's an argument to be made about correcting that behaviour and just generating everything visible. Of course there's probably good arguments against that also (I had an app that did that for a schema which had way too much permission -- startup took hours as it inspected nearly the entire db cluster). There's also considerations about how to view these tables/views as they will probably require a schema prefix "otheruser.sometable" which Django doesn't really support.

Your proposal to limit the table/views is a decent one, and should be considered independent of the problem above I think. 

You can open a ticket on trac for each of these ideas here https://code.djangoproject.com/newticket and they can be triaged and debated there. If a rough consensus can't be reached then the discussion can moved back here. You can also create a Pull Request on Github with the patch above for the limit tables ticket. Seeing code alongside a feature request goes a long way!

Django has quite a lot of text around contributions: https://docs.djangoproject.com/en/dev/internals/contributing/ so feel free to have a scan of that page for appropriate details. There should be nothing too outrageous though.

Cheers!

[José Tomás Tocino]

Hi Josh.

That's exactly what I'm saying. According to the Oracle docs [1], USER_VIEWS describes the views owned by the current user, but the views I'm concerned with are only SELECT-able by the user, that has been granted access using:

GRANT SELECT ON UXXIAC.SOMEVIEW TO MY_USER;

I'm not experienced with Oracle at all, but a quick Google search aims at a possible solution [2] to list all accessible views, not only those owned by the user. Maybe that could be a possible replacement, I'll check it with the database I'm working with tomorrow (today's a holiday here in Spain).

I've opened a ticket in Trac regarding the selection of views and tables to be inspected (https://code.djangoproject.com/ticket/25658#ticket) and a pull request with the code (https://github.com/django/django/pull/5530).

Regards.

[1] http://docs.oracle.com/cd/B19306_01/server.102/b14237/statviews_4489.htm#REFRN26305 

[2] http://stackoverflow.com/a/13742917/276451

[Shai Berger]

Hi,

I haven't looked at your PR yet, but this seems related to this old ticket:
https://code.djangoproject.com/ticket/6148

Have fun,
Shai.

On Monday 02 November 2015 02:04:32 José Tomás Tocino wrote:
> Hi Josh.
>
> That's exactly what I'm saying. According to the Oracle docs [1],
> USER_VIEWS describes the views owned by the current user, but the views I'm
> concerned with are only SELECT-able by the user, that has been granted
> access using:
>
> GRANT SELECT ON UXXIAC.SOMEVIEW TO MY_USER;
>
> I'm not experienced with Oracle at all, but a quick Google search aims at a
> possible solution [2] to list all accessible views, not only those owned by
> the user. Maybe that could be a possible replacement, I'll check it with
> the database I'm working with tomorrow (today's a holiday here in Spain).
>
> I've opened a ticket in Trac regarding the selection of views and tables to
> be inspected (https://code.djangoproject.com/ticket/25658#ticket) and a
> pull request with the code (https://github.com/django/django/pull/5530).
>
> Regards.
>
>
> [1]
> http://docs.oracle.com/cd/B19306_01/server.102/b14237/statviews_4489.htm#RE

> FRN26305 [2] http://stackoverflow.com/a/13742917/276451

[José Tomás Tocino]

Hi Shai.

That ticket seems somewhat related, but the feature we're dealing with here is, in my opinion, much simpler and easier to accomplish than the one mentioned in the ticket. What do you think?

BTW, yesterday I added the docs and release notes to the PR https://github.com/django/django/pull/5530#issuecomment-152960635

Regards

[Shai Berger]

Hi José,

On Tuesday 03 November 2015 12:58:54 José Tomás Tocino wrote:
> El lunes, 2 de noviembre de 2015, 13:22:17 (UTC+1), Shai Berger escribió:

> > https://code.djangoproject.com/ticket/6148

>
> That ticket seems somewhat related, but the feature we're dealing with here
> is, in my opinion, much simpler and easier to accomplish than the one
> mentioned in the ticket. What do you think?
>

There are several points that come to mind:

1) Some progress has been made on the "support schemas" ticket lately, and I
believe that completing that ticket may affect the way this feature is
implemented. For example, with good schema support, it seems reasonable to
take one argument -- the name of the schema to introspect. I'd hesitate to
accept the feature as suggested without considering such possibilities.

2) In order to be useful to you, it is not enough to introspect the models --
you need to be able to use them as well. That is, essentially, ticket 6148
without migrations, unless I am missing something.

To prove me wrong and/or encounter the further problems, there's two things
you can do:

a) Create the relevant models manually, and try to use them from your
application. Traditionally, this has been done by providing a quoted name with
a schema as table name -- something like

class MyModel(Model):
class Meta:
table_name = '"schema"."view"'

b) Add a test that introspects a table from another schema. On Oracle,
creating tables in another schema is probably too hard to do in a test, but
you can try to introspect views from INFORMATION_SCHEMA (with a little care
and luck, you may even be able to write a test that should work on all
backends, as INFORMATION_SCHEMA is standardized).

> BTW, yesterday I added the docs and release notes to the
> PR https://github.com/django/django/pull/5530#issuecomment-152960635
>

3) 1.9 is feature-frozen at this point -- its beta is out already. Even if the
feature is accepted as-is, it would need to target 1.10.

HTH,
Shai.

[José Tomás Tocino García]

Hi Shai

First of all, I'd like to point out that I don't have experience working with different schemas, so bear with me if I don't fully comprehend the ticket you've referenced.

1) Some progress has been made on the "support schemas" ticket lately, and I
believe that completing that ticket may affect the way this feature is
implemented. For example, with good schema support, it seems reasonable to
take one argument -- the name of the schema to introspect. I'd hesitate to
accept the feature as suggested without considering such possibilities.

But we would be running into the same problem: we would not be able to select individual tables or views to introspect, but entire schemas. If we had support, I think it'd be trivial to add an optional argument to inspectdb to select the schema to be introspected.

 

2) In order to be useful to you, it is not enough to introspect the models --
you need to be able to use them as well. That is, essentially, ticket 6148
without migrations, unless I am missing something.

Maybe I don't understand you, but I'm actually able to use the models generated with my patch. Queries are executed properly. Is that what you mean?

b) Add a test that introspects a table from another schema. On Oracle,
creating tables in another schema is probably too hard to do in a test, but
you can try to introspect views from INFORMATION_SCHEMA (with a little care
and luck, you may even be able to write a test that should work on all
backends, as INFORMATION_SCHEMA is standardized).

Honestly, I still fail to see what this has to do with my particular patch. 

I feel like this is getting overcomplicated, I just wanted to add an option to an already existing management command, that's it, nothing fancy :-/

 

3) 1.9 is feature-frozen at this point -- its beta is out already. Even if the
feature is accepted as-is, it would need to target 1.10.

I've restored the release notes for 1.9 and added the info on the 1.10 version.

--

José Tomás Tocino García
http://www.josetomastocino.com

[Shai Berger]

Just to make sure we're talking about the same thing:

Are you doing something like "inspectdb other.a other.b" or "inspectdb a b"?

I was writing assuming the first.

Beyond that -- the attitude we've always taken with inspectdb is to just make
it get all the tables, and let the user delete models they don't need (the
output is usually not exactly correct anyway).

To make it clear: I (and Josh, AFAICT) was not responding about an option to
limit the set of tables introspected, but about an option to introspect tables
which weren't introspected before. If your intention is to just limit, that's
a different story.

And I'm sorry if I make it seem complicated -- the reservation I have is that
I think selecting schemas to introspect would be more useful than selecting
tables, and so I don't want the positional arguments to be "captured" for
tables.

HTH,
Shai.

[José Tomás Tocino García]

Are you doing something like "inspectdb other.a other.b" or "inspectdb a b"?

The latter. Given a single database (and the default schema), my patch allows to just inspect tables "a" and "b".

 

Beyond that -- the attitude we've always taken with inspectdb is to just make
it get all the tables, and let the user delete models they don't need (the
output is usually not exactly correct anyway).

The problem is what I mentioned in my first message, the current implementation of inspectdb fails to get all the tables and views when the user does not own them. Therefore, if I launch inspectdb as-is, I don't get any models generated, because the introspection method used to fetch the tables and views does not return any element not owned by the user.

 

To make it clear: I (and Josh, AFAICT) was not responding about an option to
limit the set of tables introspected, but about an option to introspect tables
which weren't introspected before. If your intention is to just limit, that's
a different story.

My intention is just that, to be able to limit what tables are introspected when inspectdb is launched, regardless of what has been inspected before.

 

And I'm sorry if I make it seem complicated -- the reservation I have is that
I think selecting schemas to introspect would be more useful than selecting
tables, and so I don't want the positional arguments to be "captured" for
tables.

Well, selecting a schema would be a plausible usecase, the one I propose is a different one — a valid one as well, IMHO. I don't think they should conflict with each other, just let the user decide.

[Shai Berger]

On Wednesday 04 November 2015 16:46:35 José Tomás Tocino García wrote:
> > Are you doing something like "inspectdb other.a other.b" or "inspectdb a
> > b"?
>
> The latter. Given a single database (and the default schema), my patch
> allows to just inspect tables "a" and "b".
>

Now I get it. There are tables in your schema, which are not owned by you.
Frankly, I wasn't aware this was possible.

>
> The problem is what I mentioned in my first message, the current
> implementation of inspectdb fails to get all the tables and views when the
> user does not own them.

In that case, are you sure what you're offering is a solution and not just a
workaround? Shouldn't we make it so that inspectdb always gets all the tables
in the schema?

>
> My intention is just that, to be able to limit what tables are introspected
> when inspectdb is launched, regardless of what has been inspected before.
>

What do you thunk of Tim Allen's suggestion:

./manage.py inspectdb --tables=form_*,user_*

Thanks for your patience in this,

Shai.

[José Tomás Tocino García]

In that case, are you sure what you're offering is a solution and not just a
workaround? Shouldn't we make it so that inspectdb always gets all the tables
in the schema?

Well, as far as I'm concerned, I'd rather be able to choose what tables I want to work with. In fact, I'm not sure it's possible to know all the accessible tables/views for a single user in Oracle — at least in a way that doesn't return a myriad of built-in tables and views unrelated to my needs.

 

>
> My intention is just that, to be able to limit what tables are introspected
> when inspectdb is launched, regardless of what has been inspected before.
>

What do you thunk of Tim Allen's suggestion:

        ./manage.py inspectdb --tables=form_*,user_*

 

Well, inspectdb already does that. There's a shadow option called table_name_filter that is used by tests and does exactly that, filter the tables/views according to a given filtering function (usually one that checks whether the name starts with a string). The only problem is that it's not available to be used from the manage.py command line, because it needs you to use Python to write the filtering function. For example:

        call_command('inspectdb',

                     table_name_filter=lambda tn: tn.startswith('inspectdb_'),

                     stdout=out)

In the tests, the table_name_filter option is always filled with a function that checks the beginning of the table name.

The suggestion is certainly interesting and kind of goes hand in hand with mine. The problem I still see is what I mentioned before: how to get all the views and tables that can be read by the user so you can filter them. These are two different beasts I'm afraid.

Regards.

[Jani Tiainen]

It's actually quite common pattern in Oracle to create tables using
special admin user and then create separate users that just do have
spesific priviledges per table.

Specially old Oracle docs promoted such a pattern.

In my opinion current behavior is just fine. Also I think inspectdb
doesn't actually see any views, just tables.

[José Tomás Tocino García]

In my opinion current behavior is just fine.

How is it "just fine" if there are usecases (the one I've described, for instance) where the current behavior evidently doesn't cut it?

 

On 04.11.2015 18:26, Shai Berger wrote:

On Wednesday 04 November 2015 16:46:35 José Tomás Tocino García wrote:

Are you doing something like "inspectdb other.a other.b" or "inspectdb a
b"?

The latter. Given a single database (and the default schema), my patch
allows to just inspect tables "a" and "b".

Now I get it. There are tables in your schema, which are not owned by you.
Frankly, I wasn't aware this was possible.

The problem is what I mentioned in my first message, the current
implementation of inspectdb fails to get all the tables and views when the
user does not own them.

In that case, are you sure what you're offering is a solution and not just a
workaround? Shouldn't we make it so that inspectdb always gets all the tables
in the schema?

My intention is just that, to be able to limit what tables are introspected
when inspectdb is launched, regardless of what has been inspected before.

What do you thunk of Tim Allen's suggestion:

        ./manage.py inspectdb --tables=form_*,user_*

Thanks for your patience in this,

        Shai.

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/CuczZovhp74/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/563B087F.3090607%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Jani Tiainen]

On 05.11.2015 09:54, José Tomás Tocino García wrote:

In my opinion current behavior is just fine.

How is it "just fine" if there are usecases (the one I've described, for instance) where the current behavior evidently doesn't cut it?

Well first, inspectdb does only processes tables. As I understood your case involves views which are not traversed by Django.

Secondly, how often inspectdb is required to run with just a subset? Tim' suggestion is quite nice (wildcarded query).

Then we hit edge cases, since Django models by default are read/write how should select-only tables (or views if such behavior is implemented) should be handled? Should there be overridden methods that tries to disable invalid actions?

Now we hit another thing. If you do have spatial fields your schema will get temporary spatial objects, MDRT_*. Then usecase would be getting all other except those MDRT_* tables (or maybe exclude all tables having *$*)

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.

To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAAOwDo5ACkgXcwig1dpd4u_mdDPCe9gvfNyHue%2BbyNaN1n-qog%40mail.gmail.com.

[Jani Tiainen]

Heres a link how to fetch data about priviledges and such:

http://docs.oracle.com/cd/B19306_01/network.102/b14266/admusers.htm#i1008437

[José Tomás Tocino García]

Well first, inspectdb does only processes tables. As I understood your case involves views which are not traversed by Django.

Are you sure about that? inspectdb calls connection.introspection.table_names(cursor) that, in the case of Oracle, calls oracle.introspection.DatabaseIntrospection.get_table_list which queries BOTH tables AND views:

        """

        Returns a list of table and view names in the current database.

        """

        cursor.execute("SELECT TABLE_NAME, 't' FROM USER_TABLES UNION ALL "

                       "SELECT VIEW_NAME, 'v' FROM USER_VIEWS")

At the end of the day, views are pretty similar at the query level.

 

Secondly, how often inspectdb is required to run with just a subset? Tim' suggestion is quite nice (wildcarded query).

Well, that depends on the case. As I already stated, I'm not against the wildcarded query.

 

Then we hit edge cases, since Django models by default are read/write how should select-only tables (or views if such behavior is implemented) should be handled? Should there be overridden methods that tries to disable invalid actions?

I think that's up to the user to take care of, not Django.

 

Now we hit another thing. If you do have spatial fields your schema will get temporary spatial objects, MDRT_*. Then usecase would be getting all other except those MDRT_* tables (or maybe exclude all tables having *$*)

Again, I honestly fail to see what this has to do with my particular patch. I feel like this is getting out of hand.

[Jani Tiainen]

Maybe that view thing as been changed along the years.

My proposal would be allow two switches, inclusion and exclusion with a wildcard. Where exclusion would override any inclusion.

I guess that would satisfy most of the use cases. How that sounds?

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAAOwDo7eG913Y_5Ch1iv7J1WeVU_7bGpft%3DNSsiqj-GB%3DTa2GA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Jani Tiainen

- Well planned is half done, and a half done has been sufficient before...

[Jani Tiainen]

On 05.11.2015 15:59, José Tomás Tocino García wrote:

Well first, inspectdb does only processes tables. As I understood your case involves views which are not traversed by Django.

Are you sure about that? inspectdb calls connection.introspection.table_names(cursor) that, in the case of Oracle, calls oracle.introspection.DatabaseIntrospection.get_table_list which queries BOTH tables AND views:

        """

        Returns a list of table and view names in the current database.

        """

        cursor.execute("SELECT TABLE_NAME, 't' FROM USER_TABLES UNION ALL "

                       "SELECT VIEW_NAME, 'v' FROM USER_VIEWS")

Listing views as well is a relatively new feature (added to 1.8):
https://github.com/django/django/commit/b8cdc7dcc3fc6897fb2a75f90023f5c67aad327f

That was a bit surprise. Specially that functionality is really undocumented.

https://docs.djangoproject.com/en/1.8/ref/django-admin/#inspectdb

Documentatiuon states that it introspects tables, not views.

Documentation states that inspectdb works ith PostgreSQL, MySQL and SQLite. There is no mention of Oracle at all.

--

Jani Tiainen

[José Tomás Tocino García]

Maybe that view thing as been changed along the years.

My proposal would be allow two switches, inclusion and exclusion with a wildcard. Where exclusion would override any inclusion.

I guess that would satisfy most of the use cases. How that sounds?

As I already stated before, filtering using wildcards is not going to make it for me, because in my case I don't get a list of available tables in the first place (because the current introspection mechanism doesn't return tables not owned by the user).

[Jani Tiainen]

On 06.11.2015 10:54, José Tomás Tocino García wrote:

Maybe that view thing as been changed along the years.

My proposal would be allow two switches, inclusion and exclusion with a wildcard. Where exclusion would override any inclusion.

I guess that would satisfy most of the use cases. How that sounds?

As I already stated before, filtering using wildcards is not going to make it for me, because in my case I don't get a list of available tables in the first place (because the current introspection mechanism doesn't return tables not owned by the user).

Well maybe extending queries to do that. Wonder is there similiar issues with postgresql?

--

José Tomás Tocino García
http://www.josetomastocino.com

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAAOwDo7J33ScxGvQ3UZe2HLMLbc1Eim1TPGwqFDap6Xdp%2BJkFw%40mail.gmail.com.

[José Tomás Tocino]

Well maybe extending queries to do that. Wonder is there similiar issues with postgresql?

Nope, I've just tried granting SELECT access to a user and he can inspect the tables properly (in postgresql):

postgres=# CREATE DATABASE permissions;

CREATE DATABASE

postgres=# \c permissions;

You are now connected to database "permissions" as user "postgres".

permissions=# create table foo (id int, name varchar(255));

CREATE TABLE

permissions=# GRANT CONNECT ON DATABASE permissions to tester;

GRANT

permissions=# GRANT USAGE ON SCHEMA public TO tester;

GRANT

permissions=# GRANT SELECT ON foo TO tester;

GRANT

permissions=# \q

(ENV)vagrant@vagrant-ubuntu-trusty-64:~$ ./manage.py inspectdb

# This is an auto-generated Django model module.

# You'll have to do the following manually to clean this up:

#   * Rearrange models' order

#   * Make sure each model has one field with primary_key=True

#   * Remove `managed = False` lines if you wish to allow Django to create, modify, and delete the table

# Feel free to rename the models, but don't rename db_table values or field names.

#

# Also note: You'll have to insert the output of 'django-admin sqlcustom [app_label]'

# into your database.

from __future__ import unicode_literals

from django.db import models

class Foo(models.Model):

    id = models.IntegerField(blank=True, null=True)

    name = models.CharField(max_length=255, blank=True, null=True)

    class Meta:

        managed = False

        db_table = 'foo'

So there's that

[José Tomás Tocino]

So... is this going anywhere?

[Jani Tiainen]

Hi,

I guess it's just about crafting proper SQL for Oracle to do proper introspection and do a PR to be inline with other backends what comes to table/view discovery.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9acc3506-6585-4dd6-9463-0d431707e441%40googlegroups.com.

[Tim Graham]

One correction, inspectdb doesn't currently create models for views, but this isn't the first time that code caused confusion, see https://code.djangoproject.com/ticket/25038.

I agree that fixing the inspect SQL would be the ideal solution. José, I didn't follow the conversation closely enough to tell if you presented a reason this infeasible for some reason? I'd rather not add more complexity (arguments to inspectdb) where an easy solution already exists (removing unwanted models from the generated output).

[José Tomás Tocino]

Sorry I've been pretty disconnected from this thread. 

The TL;DR version of the current situation is as follows: in Oracle, if a user has read access to tables/views not owned by him, those are not listed by the inspection mechanism inspectdb uses, so no model is generated for them. They can be inspected if their name is explicitly given though. My PR just offered a way of manually choosing what tables/views should be introspected and have code generated for them.

The solution proposed by the user Jani Tiainen in extending the functionality of my PR so that you can use wildcards to easily match more than one table/view.

If no more complexity is to be added, then the solution would be fixing the SQL I mentioned before [1] so that it correctly reports tables the user can read... and also removes support to introspect views to properly match the expected functionality of inspectdb (that in theory should not introspect views). I think the key would be using the ALL_TABLES view in Oracle instead of the USER_TABLES view, as it's suggested here [2]. This solution is the one that more closely matches your desires, Tim.

[1] : https://github.com/django/django/blob/53ccffdb8c8e47a4d4304df453d8c79a9be295ab/django/db/backends/oracle/introspection.py#L54

[2] : http://stackoverflow.com/a/205746/276451

[Tim Graham]

If inspectdb had exception handling as proposed in https://code.djangoproject.com/ticket/14098#comment:8 would that solve the issue?