I looked again and realized that the dba_tab_cols errors not being caught
was our fault. We were overriding all of the db's execute_* methods
(cringe) and wrapping DatabaseErrors in another kind of error, so by the
time it got back to schema_parse_table, it wasn't a DatabaseError anymore
and wasn't getting caught. I got rid of the overrides, and it's now being
rescued properly.
I'm still working on the #tables and the primary keys. I'll update if I
find something. Glad to hear that all_tab_cols is working well.
On Friday, July 11, 2014 10:53:30 AM UTC-7, Jeremy Evans wrote:
>
> On Thursday, July 10, 2014 9:26:03 PM UTC-7, Jeremy Evans wrote:
>>
>> I think switching to all_tab_cols for the defaults parsing should work
>> better. I'll try that tomorrow. I wonder why the rescuing isn't working
>> for the defaults though, since it rescues DatabaseError, and the conversion
>> from OCIError to DatabaseError should have already happened (inside
>> Database#_execute). Any chance you could provide a backtrace for the
>> exception raised by DB.schema(:table_name) when using :dba_tab_cols?
>>
>
> I switched the defaults parsing in the oracle adapter to use all_tab_cols,
> and that seems to work fine. I tried as a regular user, and as long as the
> user has the permission to view the table and the table is qualified
> correctly (if necessary), it appears to work and parse the default
> correctly, which I confirmed did not happen when user_tab_cols was used.
>
> I was not able to get DB.schema to raise an exception if dba_tab_cols is
> used, it correctly rescues the OCIError and skips the default parsing. So
> I'd definitely be interested in seeing the backtrace for the exception that
> you received.
>
>
>> For DB.tables, it current uses :tabs, and for DB.views, it uses :tab.
>> Maybe you should see if there is a better way to get a list of all
>> tables/views a user has access to on Oracle.
>>
>
> I did some of my own research and testing and switched DB.tables to use
> all_tables and DB.views to use all_views, which from my testing should fix
> the issues when Sequel with a limited Oracle account.
>
>
>> In terms of the primary key parsing, the only way I think it could have
>> worked previously is if all of your tables used :id as the primary key,
>> since that's the default if the schema can't be parsed. To fix the primary
>> key parsing, you'll have to figure out why the primary key query isn't
>> working. This is the query it currently uses:
>>
>> SELECT "COLS"."COLUMN_NAME" FROM "ALL_CONSTRAINTS" "CONS",
>> "ALL_CONS_COLUMNS" "COLS" WHERE (("COLS"."TABLE_NAME" = 'TABLE') AND
>> ("CONS"."CONSTRAINT_TYPE" = 'P') AND ("CONS"."CONSTRAINT_NAME" =
>> "COLS"."CONSTRAINT_NAME") AND ("CONS"."OWNER" = "COLS"."OWNER"))
>>
>
> This works for me as a limited user, as long as I have permission for the
> table.
>
>
>> There is also DB.foreign_key_list, you may want to see if that works
>> correctly in your Oracle installation.
>>
>
> This also worked as a limited user, again assuming I have permission for
> the table.
>
> Thanks,
> Jeremy
>
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.
