Bojan: > On Fri, 2006-04-28 at 10:31 +0100, Nick Kew wrote: > >> What's missing is the option to rollback even when successful. >> In principle, a "rollback" argument to transaction_end would be >> a better way to accomplish this. What level of version bump would >> we need to introduce that? > > Given that this would break binary compatibility, it would have to be > done in 2.x. The "new function approach" could be done for 1.3.
This is great either way -- it's been on my to-do list but I've had to keep punting on it. Delighted to see something disappear off the list! As a not-committer, I don't really have a say here, but either option seems fine to me in terms of functionality (obviously). My gut instinct would be that I prefer the "rollback" argument Nick suggests purely for elegance, and that since apr_dbd is relatively new, breaking binary compatibility (so long as it's done with the appropriate version bumps) in the name of a clean interface isn't too horrible. Now I'm partly assuming that there can't be zillions of users yet relying on it in a 1.3 environment who really also need a forceable rollback feature, and that those who do can upgrade to 2.x. (After all, isn't it good to provide these little inducements to encourage folks to upgrade? :-) Whatever is chosen, kudos for dealing with this. Thanks! Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
