Railsware#blog

Catching constants was not as simple as I assumed. I’ve also tried to catch SQL queries (Adapter#execute) and load necessary fixtures immediately before SELECT/UPDATE/DELETE/INSERT. But it is also not that simple.

Transactional fixtures are inserted once per context. On every specify BEGIN..ROLLBACK transaction is performed, so there’s no need in fixture reloading.

If I catch SQL queries and load fixtures “in front of” them, they’d be wrapped into transaction and rolled back after specify is finished. Things will work, though, but much slower. Just like transactional fixtures were off.

With all that in mind, I’d like to evaluate one crazy thing to work transaction around.

The plan:

1. Add every SQL query in a queue.

If SQL requires fixture to be loaded:

2. Do ROLLBACK (loosing all the previous changes)
3. Load fixtures
4. Start transaction again (BEGIN)
5. Run previously saved SQL queries.
6. Proceed with SQL, add it to queue

If no fixtures needed, jump to 6 after 1.

It may have a drawback. In case of specify block evaluates too many SQL statements and needs some fixtures, we can get O(n*log(n)) execution time (n – number of queries), instead of O(n). But Good Boys make specify blocks short and focused, don’t they? ;-) After all, fixtures loaded in one specification are not reloaded in the other.

RSpec drives me crazy. Stay tuned.