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

[Rodrigo Moya <rmoya tsai es>]

> okay - I'm going to implement it that way.
>
> TABLES_SCHEMA,
> TABLES_SCHEMA, EXTRA_INFO
> VIEWS_SCHEMA,
> VIEWS_SCHEMA, EXTRA_INFO (same way like tables ...)
> COLUMNS_SCHEMA, TABLE_SCHEMA, ...
>
> who's collecting the definitions?
> new requests to the list?

Yes, please, we need suggestions from people knowing other RDBMS so that we can
define the more precise set of data. Actually, the schemas implemented in the
different servers are:

* GDCN_SCHEMA_TABLES -> to show list of tables with lots of (maybe) unneeded info
* GDCN_SCHEMA_COLS, table_name -> describe table
* GDCN_SCHEMA_PROV_TYPES -> list of supported types
* GDCN_SCHEMA_VIEWS -> list of views
* GDCN_SCHEMA_INDEXES -> list of indexes
* GDCN_SCHEMA_PROCS -> list of procs
[check gda.h (generated by ORBit) for the list of schemas, although note that any of
them can be removed if not needed or any other added]

So we can add to any of them a second parameter (GDCN_SCHEMA_EXTRA_INFO) which will
return extended info about the given objects, whereas the simple version will just
return, as you said, name, comments and little else

If you agree with the schema constraint stuff, this is my first suggestion on the
sets of data:

* GDCN_SCHEMA_TABLES -> name, comments
* GDCN_SCHEMA_TABLES, GDCN_SCHEMA_EXTRA_INFO -> name, owner, comments, create_cmd
(???)
* GDCN_SCHEMA_COLS, table_name -> field_name, type, size, precision, nullable,
comments
* GDCN_SCHEMA_PROV_TYPES -> name, comments
* GDCN_SCHEMA_PROV_TYPES, GDCN_SCHEMA_EXTRA_INFO -> name, owner, size, comments
(???)
* GDCN_SCHEMA_VIEWS -> name, comments
* GDCN_SCHEMA_VIEWS, GDCN_SCHEMA_EXTRA_INFO -> name, owner, create_cmd, comments
* GDCN_SCHEMA_INDEXES -> name, comments
* GDCN_SCHEMA_INDEXES, GDCN_SCHEMA_EXTRA_INFO -> name, owner, create_cmd, comments,
field1, ...field[n]
* GDCN_SCHEMA_PROCS -> name, comments
* GDCN_SCHEMA_PROCS, GDCN_SCHEMA_EXTRA_INFO -> name, owner, create_cmd, comments,
return_type, param1...param[n]

>
>
> > 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.
>
> ...downloading orb-doc and orbit-cpp-doc... :)
>
> sure to use it - gnome is using ORBit, 'cause plain c is much more portable than
> c++.
> why do you wanna switch back to c++?
>

Well, I prefer C, but I was looking for a way of organizing better all the code, to
be more portable, and orbit-cpp was one of the tools that came across, so I was
considering it. But you're right, C++ is not portable as is C, so it wasn't a good
idea. Apart from this, the server framework (which I'm working on) is an attempt to
ease all this, in plain C.