Re: [Boost-bugs] [Boost C++ Libraries] #12542: multi_index constraint violation if rollback callable is passed, but doesn't correct the issue

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #12542: multi_index constraint violation if rollback callable is passed, but doesn't correct the issue
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2016-10-22 18:14:55

#12542: multi_index constraint violation if rollback callable is passed, but
doesn't correct the issue
-----------------------------------+-------------------------
  Reporter:  Jon Kalb <jonkalb@…>  |      Owner:  joaquin
      Type:  Bugs                  |     Status:  new
 Milestone:  To Be Determined      |  Component:  multi_index
   Version:  Boost 1.61.0          |   Severity:  Problem
Resolution:                        |   Keywords:
-----------------------------------+-------------------------

Comment (by Jon Kalb <jonkalb@…>):

 I think we are mostly in agreement here and the discussion is coming down
 to two issues. One is should the library ever “take the user’s word” that
 constraints are met and the other is how reasonable/likely is it that the
 user can be certain (or uncertain) that rollback is successful.

 On the second, I have somewhat mixed feelings. I can see that in many
 cases, the only change being made is to a single field and restoring the
 old value of the field would seem to be a straightforward fix. This is, of
 course, the example I sent you. But I deliberately chose as trivial an
 example as possible for this report.

 I can imagine that in real code, the element modification might involve
 calling a transformation function whose effects might be non-trivial to
 rollback (particularly under maintenance which might not be sensitive to
 the rollback issue). The solution that would make me, as a library user,
 feel comfortable would be to have a copy of the original element value to
 restore. But since the copy would have to be made in all cases (not just
 the rollback case), the modify() member function would, in practice, have
 no advantage over the replace() member function. I’d still have to make
 copies of the element with each modify.

 On the first issue, I’m still of the opinion that the library code should
 always be defensive about any change that could corrupt the indexes and
 never just put the burden on the user to always have done the right thing.
 I think this is consistent with your own thinking when you wrote the
 comment that I quoted from the invariant-checking mode which says that any
 invariant validation is in principle a bug in the library.

 I hope that the example of a transformation function which may be non-
 trivial to rollback is sufficient to sway you, but even if not, consider
 that the library code really should defend against corruption. Perhaps it
 can’t (and for performance reasons shouldn’t) guard against Machiavelli,
 but it should always be on guard against Murphy.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/12542#comment:4>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.