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 16:03:33

#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 anonymous):

 Hi Jon,

 Let me keep this open to think it over more carefully. I am sympathetic
 to, but not fully convinced about, your position. You say:

 ''Of course if it were possible for the user to themselves verify (in the
 rollback) if the rollback has met the requirement, then it would be a
 usable feature.''

 I have a hard time figuring out what kind of rollback function would be
 unable to determine that the invariant has been restored, as this user-
 provided function is meant to ''restore the original key'', not to try
 something new (of course the user can do whatever she pleases, but that's
 another matter). Following your example, she'd do:

 {{{
 bool succeed{name_index.modify(
         it,
         [](employee& e) {e.id = 1;},
         [original_id = it->id](employee& e) { e.id = original_id;})};
 }}}

 This is not a rhetorical question: could you conceive of some realistic
 situation in which the rollback function honestly tries to restore the key
 but could potentially fail to do so (exceptions aside)? The existence of
 such scenario would certainly make it advisable to folllow your proposed
 design.

 One thing I readily concede to you is that my suggestion of using the
 invariant-checking mode for this is ill-advised. You're right this mode
 should be reserved to detect internal bugs, not user misbehaviors.

 ''This warning will certainly weaken the generally positive thrust of the
 talk on this library, but to omit the warning would be a disservice to my
 audience.''

 I don't expect from you anything less than telling the audience about any
 perceived problem you observe :-)

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