Re: [gnome-db]gda-mysql-server
- From: Rodrigo Moya <rodrigo gnome-db org>
- To: cleberrrjr <cleberrrjr bol com br>
- Cc: GDA <gnome-db-list gnome org>
- Subject: Re: [gnome-db]gda-mysql-server
- Date: 11 Apr 2001 18:32:37 +0200
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/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]