Well, possibly ... I was sort of trying to model on equal_range search, which returns pair of first, last iterators... and since it's likely it would be used on the results of equal_range search, passing them to modify_range (either as pair or as separate parameters) would be fit.On Wed, Dec 14, 2016 at 3:00 PM, Leon Mlakar <leon@digiverse.si> wrote:
Therefore, my question really is:
Is it possible to provide an "unsafe_modify" function, which does the same as "modify" but does not trigger automatic re-indexing, and an "refresh_index" function, which (manually) triggers the re-indexing?
I second this idea. Hit the same issue not so long ago. Or event better, something like modify_range(<first>, <last>, <modifier>) that would automatically re-index after modifying entire range thus avoiding the danger of user forgetting to re-index.
If it takes <first>, <last>, it's not a range :) Joking apart, better to accept anything that range-for can accept, and use Boost.Range to adapt a pair of iterators into an actual range.
I'm not sure I understand this - afaik you can already modify other key(s) via index::modify so it has to adjust/rebuild all indices.
Yes, a modify_range() or bulk_modify() or insert_better_name() would be great.But then you don't know which index needs to be rebuilt, so they must all be rebuilt.So a new API to do this could additionally explicitly spell out which ones perhaps.Although then nothing prevents other keys to be modified, breaking BMI invariants.