Re: Feature proposal: selection of views and tables for inspectdb

[Tim Graham]

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

On Wednesday, February 3, 2016 at 5:00:36 PM UTC-5, José Tomás Tocino wrote:
>
> 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
>
> El jueves, 19 de noviembre de 2015, 2:30:24 (UTC+1), Tim Graham escribió:
>>
>> 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). 
>>
>> On Wednesday, November 11, 2015 at 7:40:49 AM UTC-5, Jani Tiainen wrote:
>>>
>>> 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.
>>>
>>> On 11.11.2015 14:14, José Tomás Tocino wrote:
>>>
>>> So... is this going anywhere?
>>>
>>> El lunes, 9 de noviembre de 2015, 17:55:36 (UTC+1), José Tomás Tocino 
>>> escribió: 

 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 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 
> 

Re: Feature proposal: selection of views and tables for inspectdb

[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

El jueves, 19 de noviembre de 2015, 2:30:24 (UTC+1), Tim Graham escribió:
>
> 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). 
>
> On Wednesday, November 11, 2015 at 7:40:49 AM UTC-5, Jani Tiainen wrote:
>>
>> 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.
>>
>> On 11.11.2015 14:14, José Tomás Tocino wrote:
>>
>> So... is this going anywhere?
>>
>> El lunes, 9 de noviembre de 2015, 17:55:36 (UTC+1), José Tomás Tocino 
>> escribió: 
>>>
>>> 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 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.
 For more options, visit https://groups.google.com/d/optout.


 -- 
>> Yo

Re: Feature proposal: selection of views and tables for inspectdb

[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). 

On Wednesday, November 11, 2015 at 7:40:49 AM UTC-5, Jani Tiainen wrote:
>
> 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.
>
> On 11.11.2015 14:14, José Tomás Tocino wrote:
>
> So... is this going anywhere?
>
> El lunes, 9 de noviembre de 2015, 17:55:36 (UTC+1), José Tomás Tocino 
> escribió: 
>>
>> 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 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.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> -- 
> 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/9acc3506-6585-4dd6-9463-0d431707e441%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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/e05f5eb6-b61c-4f24-b584-ad6af18c015e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: selection of views and tables for inspectdb

[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.


On 11.11.2015 14:14, José Tomás Tocino wrote:

So... is this going anywhere?

El lunes, 9 de noviembre de 2015, 17:55:36 (UTC+1), José Tomás Tocino 
escribió:


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 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

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


--
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/9acc3506-6585-4dd6-9463-0d431707e441%40googlegroups.com 
.

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


--
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/56433744.6010104%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: selection of views and tables for inspectdb

[José Tomás Tocino]

So... is this going anywhere?

El lunes, 9 de noviembre de 2015, 17:55:36 (UTC+1), José Tomás Tocino 
escribió:
>
> 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 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
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>

-- 
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/9acc3506-6585-4dd6-9463-0d431707e441%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: selection of views and tables for inspectdb

[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 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
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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/620741bb-e6af-452d-946a-ea94796141d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: selection of views and tables for inspectdb

[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-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/CAAOwDo7J33ScxGvQ3UZe2HLMLbc1Eim1TPGwqFDap6Xdp%2BJkFw%40mail.gmail.com 
.

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


--
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/563C820E.9060606%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: selection of views and tables for inspectdb

[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).

-- 
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/CAAOwDo7J33ScxGvQ3UZe2HLMLbc1Eim1TPGwqFDap6Xdp%2BJkFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: selection of views and tables for inspectdb

[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

--
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/563C4CD4.908%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: selection of views and tables for inspectdb

[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?

On Thu, Nov 5, 2015 at 3:59 PM, 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")
>
> 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.
>
>
> --
> 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/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...

-- 
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/CAHn91odfhfnFmzx6yRcUjh9hrJdepm9_rjCGUKws0dJeEEVCNg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: selection of views and tables for inspectdb

[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.


-- 
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/CAAOwDo7eG913Y_5Ch1iv7J1WeVU_7bGpft%3DNSsiqj-GB%3DTa2GA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: selection of views and tables for inspectdb

[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


On 05.11.2015 10:28, Jani Tiainen wrote:



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 *$*)





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-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/563B087F.3090607%40gmail.com.


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




--
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/CAAOwDo5ACkgXcwig1dpd4u_mdDPCe9gvfNyHue%2BbyNaN1n-qog%40mail.gmail.com.

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




--
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/563B141B.1050802%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: selection of views and tables for inspectdb

[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 *$*)





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-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/563B087F.3090607%40gmail.com.


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




--
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/CAAOwDo5ACkgXcwig1dpd4u_mdDPCe9gvfNyHue%2BbyNaN1n-qog%40mail.gmail.com 
.

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


--
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/563B1348.1010608%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: selection of views and tables for inspectdb

[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-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/563B087F.3090607%40gmail.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
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/CAAOwDo5ACkgXcwig1dpd4u_mdDPCe9gvfNyHue%2BbyNaN1n-qog%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: selection of views and tables for inspectdb

[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.


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 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/563B087F.3090607%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: selection of views and tables for inspectdb

[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.


-- 
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/CAAOwDo5Ouabie7KeO17tRMmChuT2ZdfJjK9BO%3DfYhmsczsUP1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: selection of views and tables for inspectdb

[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.

Re: Feature proposal: selection of views and tables for inspectdb

[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.



>
> 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.

Re: Feature proposal: selection of views and tables for inspectdb

[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.

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.

Re: Feature proposal: selection of views and tables for inspectdb

[Tim Allen]

Since we're on the topic, it'd be great if `inspectdb` also accepted a 
`--tables` option, to only move certain tables in the database. For example:

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

...to import any tables starting with 'form_' or 'user_'. Allow with the 
`--database` option, this would allow moving over certain features 
app-by-app more easily when migrating a large project, without having to do 
a "dump all, remove cruft", which can be time consuming with very large 
legacy systems.

Regards,

Tim

On Sunday, November 1, 2015 at 12:52:46 AM UTC-4, 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/cf7ca8ac-b1a7-46ad-9ec9-41a7cccedfb4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: selection of views and tables for inspectdb

[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

-- 
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/CAAOwDo5p%2BPbd7%3DzL6jKwqpGgJDyxpoLsfg2TCVntodJGA_zFWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: selection of views and tables for inspectdb

[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.

Re: Feature proposal: selection of views and tables for inspectdb

[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
> 
> 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/man
> >> agement/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 '

Re: Feature proposal: selection of views and tables for inspectdb

[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

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

Re: Feature proposal: selection of views and tables for inspectdb

[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!



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.

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

-- 
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/e05210bc-919e-4d9b-94a6-a86f51ff2132%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.