On 11/18/06, Murray Cumming <[EMAIL PROTECTED]> wrote: > On Sat, 2006-11-18 at 16:09 +0100, Vivien Malerba wrote: > > > Thanks. Although the provider name must not now be provided twice, I > > > still hope that prepare_create_database() could take the new database > > > name explicitly as a parameter. > > > > The name of the database to create, even if it's mandatory is just a > > named parameter among th other required parameters, so even if it was > > passed as a function argument, you'd still have to set the other names > > parameters "manually". > > But this parameter is _always_ needed, regardless of the provider, so we > can make it > a) obvious that it's always needed. > b) easier to provide. > > Maybe there are other parameters that are always needed.
It's the only one which is always needed, but I can change the API to put the DB name in the parameters of the function. > > > > Also, it would be nice if the documentation for these methods stated > > > whether it is necessary to first open a connection. I don't see how it > > > could create a database without knowing the other connection details, > > > such as hostname. > > > > As far as I know, no opened connection is ever required to perform a > > create db or drop db. When applicable (that is when there is a distant > > server) the information to connect to the server are among the > > required named parameters in the GdaServerOperation object. > > OK. It would be nice if we could provide those connection details as > parameters, because they are always needed, but I guess there are too > many ways to specify that. Yes, there is not one common way to specify connection parameters. > > These "always needed" parameters should really be mentioned in the > documentation. There should be no need to dynamically discover what is > always needed. It's possible to update the documentation, but it will the be provider-specific. As a side note, trying to set a value to a non existing named parameter in a GdaServerOperation yields to nothing, so it is possible to try to set named parameters even if you don't know they can be set. For example you can set /SERVER_CNX_P/HOST and /SERVER_CNX_P/UNIX_SOCKET on a GdaServerOperation for a postgres provider even though /SERVER_CNX_P/UNIX_SOCKET is not a parameter for postgres, and so use the same code for either a postgres or a mysql database. vivien _______________________________________________ gnome-db-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-db-list
