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 El domingo, 1 de noviembre de 2015, 6:48:09 (UTC+1), Josh Smeaton escribió: > > 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/a89fda56-ee35-40fb-8380-4106b16d23d7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
