[Xapian-tickets] [Xapian] #266: Add more control over the automatic flush and commit behaviour

[Xapian]

#266: Add more control over the automatic flush and commit behaviour
-----------------------------+-------------------------------
 Reporter:  Richard Boulton  |             Owner:  Olly Betts
     Type:  enhancement      |            Status:  assigned
 Priority:  normal           |         Milestone:  1.5.0
Component:  Library API      |           Version:  SVN trunk
 Severity:  normal           |        Resolution:
 Keywords:                   |        Blocked By:
 Blocking:                   |  Operating System:  All
-----------------------------+-------------------------------
Changes (by Olly Betts):

 * milestone:  1.4.x => 1.5.0

Comment:

 [82569481a35b66635af393dfe8cf532d10710a01] finally removed `flush()` as a
 deprecated alias for `commit()`, which means we could reuse it to actually
 flush at some future point.

 Control of the commit threshold via an API seems like it really should be
 possible (you can already set `XAPIAN_FLUSH_THRESHOLD` but that's clumsier
 than an API call, and `getenv()` has thread safety issues so it'd be
 better not to use it in libxapian).

 Control of the '''real''' flush threshold (note `XAPIAN_FLUSH_THRESHOLD`
 really sets the '''commit''' threshold) by setting a number of changes
 seems the wrong approach though.  Whether a change is in memory or on disk
 isn't something the API user should be worrying about.  Some way to
 control the memory used seems more appropriate - how that relates to the
 number of changes varies widely depending on the size and nature of the
 changed documents.

 Related, I have a patch which implements a "commit if we haven't for at
 least $TIME_INTERVAL and aren't in a transaction" feature, which maybe
 should be merged.  The point I'm not entirely comfortable with is that it
 makes behaviour not solely dependent on inputs and so potentially
 debugging is harder.  However, time-based is clearer useful (it gives at
 least a rough upper bound on how long it will be before a change is live
 in the search) and that seems to be an inherent property.

 We should probably do at least some of this for 1.5.0.
-- 
Ticket URL: <https://trac.xapian.org/ticket/266#comment:18>
Xapian <https://xapian.org/>
Xapian