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 th
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
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
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+
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 t
>
> 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;
Yo
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 u
>
> 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, filt
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 cas
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 Toc
>
>
> 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.DatabaseIntrospectio
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
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. 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 Ga
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'
>
> 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
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. Ther
>
> 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 th
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 model
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 wou
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
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, muc
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
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 exper
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
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 statem
26 matches
Mail list logo
