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.
On Wednesday 04 November 2015 16:15:00 José Tomás Tocino García wrote:
> 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.
