Release 0.3.0-alpha-2

[Phil Bayfield]

Changes:

- Added transaction wrappers.
- Added auto-reconnect functionality to repeatable methods.
- Removed mutex lock/unlocking, as it is now more appropriate that the
application decides when thread safe functions are required and it's
considerably safer to have a sequence such as Client.Lock(),
Client.Query(...), Client.Unlock().
- Added a new test which performs create, drop, select, insert and
update queries on a simple demo table to test the majority of the
library functionality.
- Added additional error messages to places where an error could be
returned but there was no error number/string set.
- Many small changes and general improvements.

[Evan Shaw]

On Tue, Feb 8, 2011 at 4:03 PM, Phil Bayfield <ph...@bayfmail.com> wrote:
> - Removed mutex lock/unlocking, as it is now more appropriate that the
> application decides when thread safe functions are required and it's
> considerably safer to have a sequence such as Client.Lock(),
> Client.Query(...), Client.Unlock().

I agree that the application should do the locking, but if you're
going to remove all the auto locking, might it be better to just
remove the Mutex from Client altogether? (Also, in the example you've
given, the application will want to pull the full result off the wire
before unlocking.)

A few other comments on the interface:
It would be nice if there were a way to fetch the entire slice of rows
from a stored result. Right now if I want to iterate over the rows
more than once, I have to make my own slice and copy each result as I
fetch it.

Another complaint I have is that I don't know what errors I should be
looking at. There are functions that return an os.Error, but then
inside Client there's Errno and Error, which give the actual errors
from the server. I'd like some consistency here. Maybe there could be
some kind of mysql.ServerError type that represents an error from the
server and contains Error and Errno, and then Client's fields by the
same name can go away. Other ideas?

- Evan

- Evan

[Phil Bayfield]

Hi Evan,

On 8 February 2011 05:18, Evan Shaw <eds...@gmail.com> wrote:

On Tue, Feb 8, 2011 at 4:03 PM, Phil Bayfield <ph...@bayfmail.com> wrote:
> - Removed mutex lock/unlocking, as it is now more appropriate that the
> application decides when thread safe functions are required and it's
> considerably safer to have a sequence such as Client.Lock(),
> Client.Query(...), Client.Unlock().

I agree that the application should do the locking, but if you're
going to remove all the auto locking, might it be better to just
remove the Mutex from Client altogether? (Also, in the example you've
given, the application will want to pull the full result off the wire
before unlocking.)

This was a very last minute change, so not really thought a great deal about it yet. I realised that when using auto reconnect something like this was happening:

Query

Lock

Error

Unlock

Reconnect

Lock

Unlock

Query

Lock

Unlock

Which is absolutely no good for thread safety, if we have another thread waiting for a lock, it would gain the lock while the current thread is in the middle of something.

A few other comments on the interface:
It would be nice if there were a way to fetch the entire slice of rows
from a stored result. Right now if I want to iterate over the rows
more than once, I have to make my own slice and copy each result as I
fetch it.

 

Agree, this would be useful with stored results, it wouldn't work with a used result as only one row is ever in the array.

 

Another complaint I have is that I don't know what errors I should be
looking at. There are functions that return an os.Error, but then
inside Client there's Errno and Error, which give the actual errors
from the server. I'd like some consistency here. Maybe there could be
some kind of mysql.ServerError type that represents an error from the
server and contains Error and Errno, and then Client's fields by the
same name can go away. Other ideas?

With the previous client I ran into the problem that I had more errors than were provided in the MySQL error list, however in reality these errors are probably more useful to me for debugging than the average programmer using the library and I've been meaning to clean it up a bit. The public Errno/Error properties are inherited from the previous version, but the returned error from the client could be better and match it. There should probably be 2 error types, ClientError which contains error codes in the 2k range and ServerError which contains codes in the 1k range, this is the format used by MySQL.

- Evan

- Evan

--
You received this message because you are subscribed to the Google Groups "GoMySQL" group.
To post to this group, send email to gom...@googlegroups.com.
To unsubscribe from this group, send email to gomysql+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gomysql?hl=en.

[Evan Shaw]

I just reread my email through the quotes and realized it could come
off as a little obnoxious, so I apologize if it did. I didn't mean it
to.

On Tue, Feb 8, 2011 at 10:16 PM, Phil Bayfield <ph...@bayfmail.com> wrote:
> This was a very last minute change, so not really thought a great deal about
> it yet. I realised that when using auto reconnect something like this was
> happening:

> ...

> Which is absolutely no good for thread safety, if we have another thread
> waiting for a lock, it would gain the lock while the current thread is in
> the middle of something.

Right, with the way querying works now building locking into Client is
just asking for trouble (IMO).

> With the previous client I ran into the problem that I had more errors than
> were provided in the MySQL error list, however in reality these errors are
> probably more useful to me for debugging than the average programmer using
> the library and I've been meaning to clean it up a bit. The public
> Errno/Error properties are inherited from the previous version, but the
> returned error from the client could be better and match it. There should
> probably be 2 error types, ClientError which contains error codes in the 2k
> range and ServerError which contains codes in the 1k range, this is the
> format used by MySQL.

Sounds good. This would help me for sure.

One more thing I meant to mention is all the exported constants that
applications don't need access to. Any problems with prefixing them
with an underscore or otherwise making them not exported?

- Evan

[Phil Bayfield]

On 8 February 2011 09:57, Evan Shaw <eds...@gmail.com> wrote:

I just reread my email through the quotes and realized it could come
off as a little obnoxious, so I apologize if it did. I didn't mean it
to.

No worries, didn't read like that to me :) 

On Tue, Feb 8, 2011 at 10:16 PM, Phil Bayfield <ph...@bayfmail.com> wrote:
> This was a very last minute change, so not really thought a great deal about
> it yet. I realised that when using auto reconnect something like this was
> happening:

> ...

> Which is absolutely no good for thread safety, if we have another thread
> waiting for a lock, it would gain the lock while the current thread is in
> the middle of something.

Right, with the way querying works now building locking into Client is
just asking for trouble (IMO).

> With the previous client I ran into the problem that I had more errors than
> were provided in the MySQL error list, however in reality these errors are
> probably more useful to me for debugging than the average programmer using
> the library and I've been meaning to clean it up a bit. The public
> Errno/Error properties are inherited from the previous version, but the
> returned error from the client could be better and match it. There should
> probably be 2 error types, ClientError which contains error codes in the 2k
> range and ServerError which contains codes in the 1k range, this is the
> format used by MySQL.

Sounds good. This would help me for sure.

This could actually be the solution to a little problem I stumbled upon.

I like the idea of returning an error from Query function when an error packet is received and not just when an error occurs, as there should not need to be additional checks, the same applies to the NextResult function which closely resembles the query function in that it reads the result packet (OK, Error or Result Set), however with the current implementation it's difficult to distinguish what the error is, especially if sending multiple queries at once.

E.g. if I send some queries together and the results are OK, Result Set, OK, Error, Result Set

A small set of error types, the ClientError and ServerError as mentioned and the addition of a ResultError I think would be ideal for this.

One more thing I meant to mention is all the exported constants that
applications don't need access to. Any problems with prefixing them
with an underscore or otherwise making them not exported?

Probably worth looking at at some stage, I think it's about 50/50 of which need to be exported and which don't.