#18782: database "view" treated as "table" on flush (mysql)
-------------------------------------+-------------------------------------
     Reporter:  rodolfo_3            |                    Owner:  nobody
         Type:  Bug                  |                   Status:  new
    Component:  Database layer       |                  Version:  1.4
  (models, ORM)                      |               Resolution:
     Severity:  Normal               |             Triage Stage:  Accepted
     Keywords:  mysql introspection  |      Needs documentation:  0
  table view                         |  Patch needs improvement:  0
    Has patch:  1                    |                    UI/UX:  0
  Needs tests:  0                    |
Easy pickings:  0                    |
-------------------------------------+-------------------------------------

Comment (by rodolfo_3):

 The PostgreSQL code are explicitly asking for views, but it isn't true on
 sqlite3:
 {{{
   SELECT name FROM sqlite_master
   WHERE type='table' AND NOT name='sqlite_sequence'
   ORDER BY name
 }}}

 To return views using sqlite3, the "where" clause needs to be changed to
 something like
 {{{
   type in ('table', 'view') and not name='sqlite_sequence'
 }}}

 The oracle backend return just tables, ignoring views:
 {{{
   SELECT TABLE_NAME FROM USER_TABLES
 }}}


 Replying to [comment:3 akaariai]:
 > I wonder if the approach here is correct, or if it would cause further
 problems. The PostgreSQL code does this in get_table_list():
 > {{{
 >         SELECT c.relname
 >         FROM pg_catalog.pg_class c
 >         LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
 >         WHERE c.relkind IN ('r', 'v', '')
 >             AND n.nspname NOT IN ('pg_catalog', 'pg_toast')
 >             AND pg_catalog.pg_table_is_visible(c.oid)
 > }}}
 >
 > The c.relkind in ('r', 'v', `''`) says that we are explicitly asking for
 views, too... So, before committing this we should make clear if we want
 views or not from get_table_list(), and then make sure we are consistent
 on all backends.
 >
 > IMHO the problem reported in this ticket is caused by having an
 unmanaged view used by a managed model. It might be better to do a hack
 and change the model._meta.managed to False in the post_sync() signal.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/18782#comment:8>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to