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