On 27 Sep 2007, at 00:56, ara.t.howard wrote:
> > > On Sep 26, 2007, at 5:27 PM, Frederick Cheung wrote: > >> >> I think you are correct in assuming this is your problem. bits of >> create are wrapped in a transaction (eg so that the callbacks either >> run or don't etc... >> sqlite doesn't allow nested transaction, by using >> ActiveRecord::Base.connection.transaction (ie fiddling at the adapter >> level), you're starting the transaction, but not letting rails know >> about it. > > then that method should not be exposed. it should be private. we > always have > > execute 'BEGIN' > > after all. the fact that it's exposed and takes a block means it > should work for us. Hmm. If the adaptor methods were private the ActiveRecord itself couldn't call them. In general, adaptor methods are sort of down their and grungy. If you don't use the adaptor methods then the nesting and so on just works > > yup. the fact is that the multiple routes to get at transactions do > not play well together. definitely the underlying issue. >> >> Anyway, what I was wondering is why not use >> ActiveRecord::Base.transaction ? > > nested transactions are only *one* issue sane_transactions.rb > addresses, the others are > > - a throw/catch based mechanism for commit/rollback. in the current > rails there is no way, that i know of, of committing a transaction > other than falling through to the end of the block. this means all > logic must be contained in a single block, rather than split out into > methods, to commit early if logic dictates. you cannot raise because > this rolls back the exception. well if you use break then you exit the block and the transaction is committed. that's not very nice though 'break' hardly sounds like it should mean commit. > - the current mechanism is using raise/exceptions to rollback doesn't > seem to be good form: as using exceptions for control flow never is. I think it depends on how you view it: if the code inside the block raises exceptions to say 'help it's all screwed' then the current stuff is fine: it's not using exceptions to do control flow, it's using exceptions to deal with the fact that something horrible has happened. I've tended to use transactions so that should some random thing go wrong then the database isn't inconsistent: the only case in which I rollback is if an exception is thrown. However if you are going to be saying commit! and rollback! as part of your actual logic then it makes perfect sense to make them proper things (sorry can't think of a better word) > > - transactions and savepoints need to be integrated. > sane_transactions.rb does this do in a way that connection adapters > can utilize, ignore, or extend. Coolio! > this, and the nested transacitons work across the board in a POLS way > regardless of the entry point. the main benefit i see, however, is > that the implementation is also vastly simpler with far less state > tracking - this is mostly due to the use of throw/catch. > Apart from ActiveRecord::Base.connection.begin_db_transaction for some adapters (eg the mysql/postgres adapter implementation just calls execute 'BEGIN') (and of course execute 'BEGIN'). That's sort of adaptor dependant I suppose. Fred --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
