Re: gnome-db team
- From: Rodrigo Moya <rmoya tsai es>
- CC: gnome-db-list gnome org
- Subject: Re: gnome-db team
- Date: Wed, 29 Mar 2000 13:43:19 +0200
>
> > So, I'd like to start defining the config component stuff. The bonobo
> > part is clear, isn't it? We'll code a sample bonobo control which will
> > just include a container widget created by each of the providers' config
> > component. My idea about what the component will do is that it should do
> > whatever you want (and can). That is, the ODBC widget will be just a DSN
> > configurator, as the windows version does, but the oracle provider can,
> > for example, allow the creation of users, databases, ... management of
> > tablespaces, quotas, etc, and any other provider whatever is possible
> > with the underlying database. What do you think?
>
> I think that there should actually be several bonobo components provided by
> each provider, so that an application can choose which one to display. The
> different components I see would be:
> * one to allow configuration as defined above, but limited to configure
> datasources
> * one to allow the creation/destruction of databases
> * one to allow the manipulation of users and their rights on tabes and databases
> * one to allow the creation of tables and other objects more or less specific to
> each provider (sequences,...)
> * and other ones for tablespaces, quotas, etc.
>
> What needs to be done is that a client must be able to know which components
> are avaliable for a provider (maybe with the supports() function)
>
Good idea! This could be very useful if you want to provide some ways of
administering your database but not all in an application. For the gda-manager, it
will load all available components, but for example, in gASQL, you may want to let
the user create its data sources by just inserting the first component (...but
limited to configure datasources).
>
> >
> > Also, I'd like all of the providers' people to say your opinion about
> > the interface in the servers, the missing schemas (this is very
> > important), .... because as we're starting to have several stable
> > providers, I don't want to add more and more providers if the design
> > does not fit any kind of data source.
> >
>
> I will make a small modification to the TYPES schema to include the number of
> arguments necessary to create a table (for the majority it will be 0, but for
> example for data type varchar it will be 1, at least under Postgres). We should
> also add a schema to know, for a given data type, what are the type of the
> arguments necessary. [ Rodrigo, we talked about this at GUADEC ]
Yes, now I remember. With this we should be able to generate a CREATE TABLE command
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]