Em 24-04-2012 12:27, Jeremy Evans escreveu:
On Tuesday, April 24, 2012 6:55:29 AM UTC-7, Rodrigo Rosenfeld Rosas
wrote:
Hello,
I can deal with transactions in RSpec using
around(:each){|example| DB.transaction(savepoint: true) {
example.run; raise Sequel::Error::Rollback } }
This is pretty much the recommended way of doing things. However, the
:rollback=>:always option exists to make it slightly easier.
Thank you, I haven't noticed this option before.
Moving on, the problem is that I'd like to have a set of records
to be created for context, but only once or it would be too slow
to run the spec.
Then just add the records before the spec and delete them after:
before(:all){# Add some records here}
after(:all){# Delete the records here}
This is not that easy. For example, if you write
FactoryGirl.create(:user), this might as well create a role or other
records in the database. It is hard to keep track of every record
created behind the scenes, so it would be a nightmare to maintain
something like this.
But RSpec doesn't support an around(:all) and Sequel doesn't
support the usage of transactions without the use of blocks.
Well, you could always ask the rspec guys to implement around(:all).
I've already done, but I think this is a limitation from both sides and
should be fixed in both. There are other situations while you might want
to start the transaction and rollback or commit them in separate methods.
The fact that it doesn't already exist breaks my POLS.
Do you mean Principle of Least Surprise? Yes, it surprises me too.
I'd like to be able to do something like this:
context "some sample records exists" do
before(:all) do
@sample_records_transaction = DB.transaction(savepoint: true)
create_sample_records
end
after(:all) { @sample_records_transaction.rollback! } # or even
raise Rollback
# examples here
end
Could you please add support for using transactions this way?
No. Because of how the connection pool works, you need to use blocks
for transactions.
Sorry, could you please elaborate on this? What do you mean?
You are free to implement such things yourself if you want. In single
threaded mode, you could probably get something that works OK.
Sorry, but I couldn't understand what is the thread-safety role here.
Thanks,
Rodrigo.
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sequel-talk?hl=en.
