Upon fixing the reference counter thing in the previous commit, this bug
caused tests to fail. We have to _rollback() properly any time we've
called _begin_work(), particularly before die()'ing after a
_begin_work().
This code was clearly not correct as it was. The main problem is that I
was envisioning begin_work/commit pairs as always matched, but of course
if we die in the middle of a transaction, the counter has to be reset.
That's why we have to set the $dbh->{HandleError} in new() to a
subroutine that does that.
Also, we need to similarly wrap rollback() calls. When rolling back, we
have to reset the counter as we're not going to commit() (that's the
point).
These tests mostly fail, although a few pass automatically:
not ok 26 - addPostalAddress: dies for undefined id
not ok 27 - addPostalAddress: dies for non-numeric id
not ok 28 - addPostalAddress: postal address undefined fails
ok 29 - addPostalAddress: type is not added when other input paramaters are invalid
ok 30 - addPostalAddress: addPostalAddress of a valid formatted_address works.
ok 30 - addPostalAddress: addPostalAddress of a valid formatted_address works.
not ok 31 - addPostalAddress: id returned is sane.
Goal is to implement those and make sure they all pass.
Properly map email address to supporter when email address is added.
Test now passes:
ok 12 - addSuporter: email address mapping is created on addSupporter() w/ email address included
All of the addSupporter must now succeed (including sub-operations like
addEmailAddress).
This causes one failing test to now pass:
ok 55 - addSupporter: fails if email_address given but email cannot be inserted
Now that we are properly nesting transactions, this test is shown to be
incorrect. Namely, it is indeed correct that the entire add should fail
when we've given something invalid: we don't want to add the requestType
if it wasn't already there if the parameter to add
addRequestConfigurations was invalid.
I want to be able to nest begin_work()/commit() calls. Years ago (in
the mid-1990s), when I did database programming, this is how we handled
this scenario. I have no idea if there is now a "better way" to do
this, but some quick net searches found nothing that is recommended, but
I admittedly didn't search that hard.
This should work for our needs.
This new section of tests verifies that when the database disappears
underneath or has other types of problems that the API still functions
as expected.
The second test committed herein currently fails.
A basic implementation of getRequestConfigurations and tests to go with
it.
Also added here is the test to verify that no items are added when
duplicates are included.
Adjusted one test slightly: there was a missing argument. Also,
corrected test count.
While implementing, I realized a failure mode that forces a rollback:
duplication on the input list of configurations. Tests are now needed
for that.
