[gnome-db]gda-mysql-server

["cleberrrjr" <cleberrrjr bol com br>]

Hi All,

As I said a couple of weeks ago, I'm
interested in helping
out doing tids and bits on the MySQL
provider.

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.

First, I prepared a more-or-less
accurate summary of the
 a MySQL driver:

Function					Status
gda_mysql_connection_new			Implemented
gda_mysql_connection_open
Implemented
gda_mysql_connection_close
Implemented
gda_mysql_connection_begin_transaction
Not Implemented
gda_mysql_connection_commit_transaction
Not Implemented
gda_mysql_connection_rollback_transaction
Not Implemented
gda_mysql_connection_open_schema
Implemented
gda_mysql_connection_modify_schema
Not Implemented
gda_mysql_connection_start_logging
Not Implemented
gda_mysql_connection_stop_logging		Not
Implemented
gda_mysql_connection_create_table		Not
Implemented
gda_mysql_connection_supports
Implemented
gda_mysql_connection_get_gda_type
Implemented
gda_mysql_connection_get_c_type			Not
Implemented
gda_mysql_connection_sql2xml			Not
Implemented
gda_mysql_connection_xml2sql			Not
Implemented
gda_mysql_connection_free
Implemented
gda_mysql_error_make				Implemented
gda_mysql_command_new				Implemented
gda_mysql_command_execute
Implemented
gda_mysql_command_free				Implemented
gda_mysql_recordset_new				Implemented
gda_mysql_recordset_move_next
Implemented
gda_mysql_recordset_move_prev			Not
Implemeted
gda_mysql_recordset_close
Implemented
gda_mysql_recordset_free			Implemented

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

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:

* 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.

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.

Cherrs

Cleber Rodrigues
cleberrrjr bol com br


__________________________________________________________________________
O BOL é Top3 no iBest! Vote já para torná-lo Top1!
http://www.bol.com.br/ibest.html