Re: fixes on gda-oracle-server (fwd) [WatchDog checked]

[Rodrigo Moya <rmoya tsai es>]

Hi!

>
> anyway.. the fact is, if you wantto do some nice things with what is already
> defined,
> you can do it without having the final specs.

There are no specs at all, we can even think on rewriting the suite if it does
not suit our needs, but, of course, if it's possible to go the easy way, which
is fixing and improving what is already done, better.

> I know it is not so easy to
> do.. I myself find lot of dificulties in trying to do something without
> feeling "safe" about the bases but ayway, this is the way it goes for now.
> I think the actual definition is "enough" for many nice things to be done,
> and if you think you need
> more information, that could come just the way you are saying, then there is
> no need
> to rewrite the previous definition.. it is more like an additional stuff..
> you can modify the idl,
> adding the information firelds you need accesible through the function call
> "extra_info" or whatever,
> and then use it for the specific purpose. the whole stuff could then be
> rewrote in a cleaner way.
> I supposeit won't be easy to think about all the needs of the recset
> definition without trying some programs.. and seeing new needs...

That's why the schema implementation is like this. There is a function called
gda_connection_open_schema, which accepts a variable list of constraints. These
constraints is what we must define (and, of course, the data returned by each
one). There is no need to touch the IDL files. For example:

TABLES_SCHEMA -> returns table name and comments
TABLES_SCHEMA, EXTRA_INFO -> table name, create_command, .......
COLUMNS_SCHEMA, TABLE_NAME, "table_name" -> description of table "table_name"
...
This is what we must define. A server could respond to all of these schemas, but
some other may just respond to the ones it wants (or can). If a server responds
to a schema,  it must return exactly the same data as defined by this schema,
but it can ignore the specific schema and return nothing.

About what you say about the bases, I was thinking to change the server's
implementation to orbit-cpp, which, as I've seen, produces an easier-to-read
code. One of the problems right now is to understand the ORBit stuff, it took me
months to understand it.

>
> >another question: the button data in the object-browser of the gdafe -
> shouldn't
> >be there a select count(*) over the table with an question to the user if
> there
> >are more than xxx rows? Or is there a max_rows anythere in the grid (I
> still
> >hadn't have a look to the source :).
>

This is one of the missing features in the GnomeDbGrid widget. This gave me an
idea, and I'll try to implement it on the weekend: to load grid data
asynchronously through the use of timeout functions or something like that.

P.S: please, Stephan, send mails to the list!