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

[Rodrigo Moya <rodrigo gnome-db org>]

On Fri, 2003-01-31 at 00:50, Steve Fosdick wrote:
> > > 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 don't have a trong opinion on what it should return. Anyone have any
comments on what would be better?

> 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?
>
so far, that's the way other providers work. At least, this is true for
postgres and mysql. Holger, what FreeTDS/Sybase providers do?

>   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"); ?
> 
for strings: gda_value_new_string (NULL);

But what I am saying is that we should use gda_value_new_null, and then
have mergeant, when checking the types, understand that a NULL value is
a correct value, regardless of the type (right now it checks the types
of the columns, and if they're not what it expects, it ignores the
schema data). Vivien, do you think that's a good plan?

cheers