> > 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. > > 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. > -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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/CAAOwDo6HzqOS1TPWmNnHxJAKhJyP3vBzV6GfFw9oNArPnCzBKw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
