Re: [gnome-db] Oracle, Table Names and Progress



On 31 Jan 2003 00:04:26 +0100
Rodrigo Moya <rodrigo gnome-db org> wrote:

> > When asking Oracle to describe a table though, as done for
> > get_schema(GDA_CONNECTION_SCHEMA_FIELDS) oracle looks only in the
> > calling user's schema for the table concerned.
> > 
> what do you mean, it queries ALL_TABLES, or another view/table?
> (soory, but don't have the code handy right now)

No, in order to get the column list for a table gda-oracle-provider uses
the Oracle call OCIDescribeAny rather than issuing an SQL statement
against one of the built-in views like ALL_TABLES.

> > 1. Use the USER_TABLES view instead of ALL_TABLES.  This would
> > restrict the table list to those tables owned by the calling user
> > rather than those accessible to the calling user.  The list of
> > tables would be shorter but all would be describable.
> > 
> I'm not sure what would be best for Oracle, but other providers are
> just returning the list of tables owned by the current user, or, in
> some others, the tables availables in the current database.
> 
> We don't have a concrete rule for this in libgda, maybe we should add
> it.

I would be good to be consistent across all providers in how this is
handled.  For a single-user database it is not an issue but for any
multi-user database we should specify if GDA_CONNECTION_SCHEMA_TABLES
normally returns tables owned by the current user or also returns those
he can access from elsewhere.

I think restricting the list to tables owned by the current user would
solve all the "object not found" errors we are having with the oracle
provider so it is an attractive idea to me - how do other people feel
though?  Do people using the tool want to see the table definitions for
other people's tables?  If so should it be the default or could it be an
optional extra parameter when asking for GDA_CONNECTION_SCHEMA_TABLES?

> hmm, this doesn't seem right, since some providers don't even know
> what an owner is. Although, well, they could just ignore the
> parameter. But I think it's not a good idea to have this requirement
> on clients.

That's a good point.

> > Appart from the above I have added the missing column (default
> > value) to the output of get_schema(GDA_CONNECTION_SCHEMA_FIELDS) and
> > now get a useable properties dialog from mergeant's tables view. 
> > That does raise another question though - what should a provider
> > return in columns which have no meaning for the database concerned -
> > is there a convention for NULL values?
> > 
> yes, you should create a value of the expected type of value NULL,
> since Mergeant checks for the types of the columns. Although I guess
> we should be using gda_value_new_null (creates GdaValue's of type
> GDA_VALUE_TYPE_NULL) for this kind of fields. Since setting right now
> null values for types other than strings is quite difficult.

So, for example, gda_value_new_string("NULL"); ?

> I'd say yes, since it might be easier later on to commit/review your
> next set of patches.
> 
> As soon as you send some patch, please apply for a CVS account (mail
> cvsmaster gnome org and add me on the CC).

OK.

Steve.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]