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.

Oracle GIS update

[Jani Tiainen]

Hi, I finally had time to get back on Oracle GIS issues.

I ran test suite against 1.9.x and 7 tests fails.

3 tests are most probably due different algorithms used to calculate
geographical distance and areas. My proposal for fix is to use backend
spesific values.

Failing testcases are:
==
FAIL: test_distance_function
(gis_tests.geogapp.tests.GeographyFunctionTests)
AssertionError: 4899.67677194225 != 4891.2 within 2 places
==
FAIL: test_geography_area (gis_tests.geogapp.tests.GeographyFunctionTests)
AssertionError: 5439100.13586914 != 5439100.95415646 within 5 places
==
FAIL: test06_geography_area (gis_tests.geogapp.tests.GeographyTest)
AssertionError: 5439100.13586914 != 5439100.95415646 within 5 places
==



4 tests are unknown failures that require further investigation.
Failing testcases are:
==
FAIL: test_difference (gis_tests.geoapp.test_functions.GISFunctionsTests)
==
FAIL: test_difference_mixed_srid
==
FAIL: test_intersection (gis_tests.geoapp.test_functions.GISFunctionsTests)
==
FAIL: test_sym_difference
(gis_tests.geoapp.test_functions.GISFunctionsTests)
==

-- 
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/CAHn91ofJ0QQjKJ9KZXwBMLhyD59AN6sxq%3D_JtNz6xeuujH8tEw%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]

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: Some love for admindocs

[Tim Baxter]

For the reasons outlined in the comments there, and for the reasons 
outlined by Zan above, I think it should be kept and developed. I believe 
it's one of the most-underutilzed features in Django, and is invaluable for 
both beginners finding their way around and experienced developers who need 
a solid overview of the third-party lib they just grabbed.

Yes, there are shortcomings, but that's reason to improve them, not throw 
them out.


On Friday, September 25, 2015 at 2:05:14 PM UTC-5, Tim Graham wrote:
>
> It might be interesting to fork it and develop your vision as a separate 
> project so you can iterate more quickly. At some point we could evaluate 
> whether the existence of an actively maintained external package would 
> allow us to deprecate the version in Django itself (as has been previously 
> proposed but rejected because it doesn't have a big maintenance overhead 
> and some people like it).
>
> Here's that discussion: 
> https://groups.google.com/d/topic/django-developers/0-qFyCPuSRs/discussion
>
> On Sunday, September 20, 2015 at 8:39:29 PM UTC-4, Žan Anderle wrote:
>>
>> Hi folks!
>>
>> I've been thinking about admindocs lately and that they would really 
>> deserve more attention than they currently get. It's a quite useful feature 
>> and I think a very underrated one.
>>
>> They were initially there to provide documentation for 'front-end 
>> people', when working on templates. While this may still be useful, we've 
>> already discussed that nowadays it's more common to use admindocs as 
>> internal documentation for developers. I think I'd be great if this 
>> position was reaffirmed inside the Django project. Some of the ways we 
>> could do that:
>>
>> 1. Have that position more clearly stated in the documentation for 
>> admindocs
>> 2. Mention admindocs in other parts of the Django documentation. For 
>> example, it seems that following FK relations is often a lot easier with 
>> admindocs. Maybe that should be mentioned somewhere?
>> 3. Mention admindocs in the tutorial. Not sure about this one, since it 
>> could just add unnecessary weight. But it might also make life easier for 
>> some people.
>> 4. Add some possible new features:
>>
>>- documenting management commands 
>>- having some kind of README per app. Tim Baxter provided an 
>> example/possible 
>>implementation 
>>
>> 
>>  
>>of this on the irc channel. 
>>
>> Anyway, I'd love to hear your thoughts.
>>
>> Best,
>> Žan
>>
>

-- 
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/117ed8f4-3b64-46d0-9770-053147fedb7f%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]

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