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! On Sunday, 1 November 2015 15:52:46 UTC+11, José Tomás Tocino wrote: > > 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 > -- 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/c6f9547e-baa7-4625-906b-b45d33f883c9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
