Anyway you can also lookup mysqlplus for another ruby mysql non-blocking drivers, hopefully with good success

Aha, yes spotted this the other day. This pretty much solves the problem, great work!

(For anyone following: http://github.com/oldmoe/mysqlplus/tree/master )

tele-working?

It’s quite a core role in small company team, so while a mix of working from home and from the office might work, a full-time telecommute (esp from a different time-zone) probably wouldn’t at this stage.

There is a good chance we’ll have contract work in future that could be done remotely though - so feel free to send us a CV if there are aspects of our work that appeal.

Anyway you can also lookup mysqlplus for another ruby mysql non-blocking drivers, hopefully with good success

-=R

You’re absolutely right! I just gave it a try and it nicely ran everything in parallel

My queries are simple (I’m not even using Rails), so this is definitely the best option.

Thanks!
Sérgio

If scalability/concurrency matters more than speed you could give the native Ruby MySQL API a try. I believe this is non-blocking on Ruby threads as it uses the native ruby libraries for its IO.

To do this you have to do:

require ‘active_record/vendor/mysql’
require ‘activerecord’

to stop activerecord loading the C-extension-based mysql gem.

This isn’t ideal though, the native ruby implementation is a fair bit slower and doesn’t seem to be recommended for production use. It’s worked ok for us although haven’t really tested it under high load yet.

If you do come across any solution, even if just experimental, please let me know; otherwise I’ll have to implement the process option or code a python script just for that.

Cheers,
Sérgio

I thought {} was synonymous with Hash.new

Therefore

{{} => true}[{}]

generates 2 different hashes with different object_ids and so will return nil

It is Hash.new yes - {{} => true} is a Hash which has one key/value pair - the key is {} (an empty Hash) and the value true.

[] is then the lookup method for that Hash - so we’re looking up the value corresponding to the key {}. We expect to get true, but it doesn’t find the value, due to {}.hash not being fixed for different instances of an empty hash.

h = Hash.new
empty_hash_as_key = {}
another_empty_hash = {}
h[empty_hash_as_key] = true

h[another_empty_hash]
=> nil

-Matt

From my naive non-software enginneering perspective the first three code examples behave exactly as I would expect:

I thought {} was synonymous with Hash.new

Therefore

{{} => true}[{}]

generates 2 different hashes with different object_ids and so will return nil

and its the same with

{{}=>true, {}=>true}

the two hashes have two different object_ids so are different keys

where as

{} == {}

compares just the contents of both hashes and returns true.

There is no === operator for Hashes which I would expect to assert that both objects have the same object_id and the same contents.