Roger,

Sets the TCP_NODELAY socket option

Roger,

Initial thoughts with this was :

If the user / client is not interested in a result, let it be fire and forget and thus also don’t flag as an async operation in progress.

Some ‘say what?’ moments after revisiting months after :-)

I smell a cleanup in progress …

- Lourens

what does fastsend do do you know? thanks!

I like this one. Preserve sanity for end users by disallowing more than one query :P

is this deprecated? Question: why should the value of query_with_result actually affect whether or not one sets async in progress? Thanks!

Roger,

Deprecated – initially just played with this for mysql_adapter – the same information can be made available by piggy backing off async_in_progress and exposing a public method.

Please do turn a blind eye, if possible :-)

- Lourens

isn’t is kind of scary to allow them to set busy=

does busy mean something different than async_in_progress? I guess it means “async_in_progress or async might become in progress right soon”?

oh yeah—you’re right

I think the comment only applies to test_all_hashes.rb, and was accidentally copied into the other two files?

these comments were actually true, at least for my machine at the time.

so MYSQL_STATUS_READY means that the socket is ready for writing? Wow their docs seem so hard to parse…

Roger,

There’s also the option to use MYSQL_STATUS_READY, which libmysld sets as the status member of the Mysql struct.I found this to be slightly more reliable than vio_poll_read as the latter is best suited for poll, not select.

http://github.com/oldmoe/mysqlplus/commit/9d66a3b71e91688e4b4a90d056dbc8bbbb88dc7f

I’m not sure what vio_poll_read does—does it block? I wonder if we can skip the rb_select somehow…but this should be all right.

I’m not sure if NILorSTRING returns ruby objects only…

should be fixed now

found the bug, all_hashes should return an empty array on empty result sets. This implementation returns nil instead

@tmm1, I am getting reports of a failing find_by_sql which complains about trying to collect! from a nil value.

this means that AR’s select() method (implemented in the adapter) returned nil. The implementation of select is trivial

def select(sql, name = nil) @connection.query_with_result = true result = execute(sql, name) rows = result.all_hashes result.free rows end

but It seems some people will get rows = nil (which is the case if all_hashes is called twice)

I have tested it myself and found it to work!

What are the issues?