Re: [gnome-db]gda-mysql-server

[Rodrigo Moya <rodrigo gnome-db org>]

On 10 Apr 2001 21:14:24 -0300, cleberrrjr wrote:
> Hi All,
> 
> As I said a couple of weeks ago, I'm
> interested in helping
> out doing tids and bits on the MySQL
> provider.
> 

that's perfect. Would you like to be added as maintainer for the MySQL
provider in bugzilla. If you want, we can set up a @gnome-db.org account
for you so that you get automatically admin privileges in bugzilla when
you create your account.

> I actually got to know the MySQL
> provider a bit and would
> like to discuss a couple of topics.
> It's clear to me now,
> though, that this provider needs quite
> a bit of health
> care.
> 

yes, it indeed does :-)


> That means we have only 58% of the
> functions implemented (some
> of which are not completely
> implemented or buggy).
> 

for example the open_schema method. It just returns a subset of all the
required schemas

> I'd like to start discussing the
> *_transaction() family. MySQL
> is quite problematic when it comes to
> transaction support as
> you might know. This support depends
> on:
> 

yes, we talked some time ago about this, and the only thing that was
raised was to simulate transactions by using MySQL locks. The other
possibility would be to just return a NOT_SUPPORTED error when using
those methods.

> * whether mysqld built with support
> for BDB (Berkeley DB) tables
> * whether the table type is BDB (not
> MyISAM nor ISAM)
> * whether AUTOCOMMIT option is set to
> 0
> 
> Regarding the first issue, MySQL
> client API provides no clean way
> of finding whether the server supports
> transactions or not. This
> could be accomplished with something
> like this:
> 
>       CREATE TABLE tst_support_test IF NOT
> EXISTS (
>       i int
>       ) TYPE=BDB;
> 
>       SET AUTOCOMMIT=0;
>       BEGIN;
>       INSERT INTO tst_support_test VALUES
> ('98765');
>       ROLLBACK;
>       DROP TABLE tst_support_test;
> 
> This could clear up the first issue,
> but I'm ashamed of calling
> this a viable solution. 
> 
> Things can get even worse (regarding
> the 2nd issue), from the MySQL
> documentation "You can combine TST and
> NTST tables in the same statements
> to get the best of both worlds."
> 
> How can we know in advance whether all
> tables are transaction safe?
> I can't realize how.
> 
> In my opnion, there are times (at
> least if you're using MySQL) when
> the client has to be the one to pick
> what is supported by the server.
> 

yes, that's what the gda_connection_supports method does. It lets the
client ask the provider about its capabilities. BTW, now you're on it,
please have a look at the gda_mysql_connection_supports function, and
complete it with all the available features.

> If this happens to be the way to go,
> it would reflect having a 
> gda_connection_set_support() (or smth
> like that) function.
> 
> I believe a client usually have this
> kind of knowledge about the database
> it's accessing. Once the client
> requests transaction support (which
> could be enable/disable by default in
> a provider basis), the *_transaction()
> functions would act accordingly.
> 
> I'm dying to get this done. Please let
> me know what you guys think
> about all this.
> 
as I said, you've got 2 options: simulate transactions, or just have the MySQL

not supporting transactions at all, and act accordingly in
gda_*_connection_supports (by returning FALSE when asked for the
GDA_Connection_FEATURE_TRANSACTIONS)

cheers


-- 
Rodrigo Moya <rodrigo gnome-db org> <rodrigo ximian com>
http://www.gnome-db.org/