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 <theom...@gmail.com
> 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
> <https://groups.google.com/d/msgid/django-developers/CAAOwDo7eG913Y_5Ch1iv7J1WeVU_7bGpft%3DNSsiqj-GB%3DTa2GA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> 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.
