Re: [gnome-db] Mergeant forms status

[Vivien Malerba <malerba gnome-db org>]

Le sam 14/09/2002 à 12:54, Rodrigo Moya a écrit :
> > > > > > > Also, the dialogs that ask whether to run the SQL commands or
not
> > > > should
> > > > > > > be removed. Or are those just displayed because of debug
being
> > > > enabled?
> > > > > >
> > > > > > For now they are enabled, but I want to convert this into a
global
> > > > > > option: whether to ask confirmation before SELECT, UPDATE,
INSERT
> > or
> > > > > > DELETE calls (so each user can set wether he wants to check the
> > queries
> > > > > > before they are commited). The default would be no confirmation
for
> > > > > > SELECT, and confirmation for the others.
> > > > > >
> > > > > nice, leave that to me, since as I told you, I'll be working on a
> > unique
> > > > > preferences dialog, so I'll include this option also.
> > > > >
> > > >
> > > > Ok. For this I will modify the ServerAccess object and issue a
> > > > confirmation dialog whenever necessary from the user preferences.
> > > >
> > > what do you mean?
> >
> > I was thinking of having the following preferences as booleans:
> > - ask for confirmation before a SELECT query
> > - ask for confirmation before an INSERT query
> > - ask for confirmation before an UPDATE query
> > - ask for confirmation before a DELETE query
> >
> > and make the ServerAccess object checks those preferences before any
> > query is sent to the DBMS and when necessary ask for a confirmation
> > before actually sending the query. All the GUI will be in your settings
> > dialog (I suppose this is the settings_get_show_confirmation_dialog
> > accessor function you mention farther down).
> >
> yes, I'll rename the file settingsdialog.c to settings.c and add there
> all accessor functions.

Ok.

>
> > >
> > > Also, what are you using for configuration right now? just the XML
file
> > > describing the connection? I think we should use GConf.
> >
> > For now an XML file (for a given "document") holds: the database
> > structure, the queries definitions, the forms (QueryEnv, etc)
> > definitions, the layout of the relations widgets and the plugins
> > association with data types and other objects (plugins can be
associated
> > to data types, table's fields and query's fields).
> >
> > Also there are a few parameters which are stored in the old
> > ~/.gnome/mergeant and ~/.gnome_private/mergeant. These parameters
should
> > go into GConf.
> >
> ok, I'll look for that and replace them with calls to the accessor
> functions in settings.c

Ok.

>
> > I think we should keep all the configuration parameters which are
> > dependant on the contents of a "document" in the corresponding XML file
> > (this is what is done now, no need to change it), and we should put all
> > the parameters which are not dependant on the "document" in GConf.
> >
> yes, makes sense.
>
> > >
> > > Also, I wanted to start looking at what config settings we want to
have,
> > > as soon as I finish moving the plugins configuration to the new
settings
> > > dialog, so, what do we want to have as preferences? I've thought so
far
> > > about:
> > >
> > > Interface
> > >    Save window position on exit (yes/no)
> >
> > This info goes into GConf keys.
> >
> > > Database
> > >    Connection preferences
> >
> > The password and user names can go into GConf keys.
> >
> oh, right, connection preferences are just for the current file being
> opened in mergeant, right? If so, I think we should also keep the
> username and password in the XML file. Of course, we should be crypting
> the password.

Yep. How would you like to encrypt the password? (If the user needs to
enter a password to decrypt the stored password, then there is no point
storing the password at all!)

>
> > > Plugins
> > >    The current plugin preferences dialog
> >
> > This information goes into the XML file.
> >
> hmm, why?

Because plugins can be associated to:
- DBMS data types => this could go into GConf
- Tables' and query's fields => this is specific to the "document" =>
need to go into XML file

Maybe we could provide some keys in GConf to propose some initial
plugins associations and then save everything into the XML file.
For example if the user connects to a postgres DBMS for the first time,
Mergeant could try to find a default plugin to display CIDR data types
(which is specific to postgres).

>
> > Maybe also:
> > - users management
> > - saving a copy every <min> intervals?
> >
> > I don't see any other for now.
> >
> ok, I'll add the basic stuff, and then, as we need more options, we'll
> add them.

Right.

Thanks,

Vivien