[Xapian-tickets] [Xapian] #709: Expose Database::get_revision_info()

[Xapian]

#709: Expose Database::get_revision_info()
-------------------------+-------------------------------
 Reporter:  Kronuz       |             Owner:  olly
     Type:  enhancement  |            Status:  assigned
 Priority:  high         |         Milestone:  1.4.1
Component:  Library API  |           Version:  git master
 Severity:  normal       |        Resolution:
 Keywords:               |        Blocked By:
 Blocking:               |  Operating System:  All
-------------------------+-------------------------------
Changes (by olly):

 * status:  new => assigned
 * milestone:  1.4.x => 1.4.1


Comment:

 OK, so you do need the revision number itself.

 Than I think the cleanest way to resolve this is to add a method which
 just returns the revision number as a suitable integer type, and make it
 throw an exception for multi-databases and for non-disk based databases
 (or even for everything but glass maybe - what do you support WAL for?).
 Then Xapiand can just use that and not have to worry about the encoding of
 it, or tying down the encoding Xapian uses internally.

 Longer term, perhaps it would make most sense to move the WAL support into
 Xapian, but trying to do that first will mostly ensure that nothing user-
 visible happens for some time...

 I'd be tempted to mark the method as internal or similar, with a note
 encouraging people to talk to us before using it, so we're aware of the
 impact of changing or removing it (so if Xapiand remains the only user, we
 only need to coordinate future changes between the two projects).

 For example, Richard wondered about ways to handle the revision counter
 hitting its limit gracefully - making it 64 bit would make this impossible
 in practice (if you managed to commit a revision every '''nanosecond''',
 it'd still take 584 years to exhaust a 64-bit counter), or else invalidate
 revisions `[0,range/2)` when the counter hits `range` and wraps to `0`,
 and invalidate `[range/2,range)` when the counter hits `range/2` and use a
 custom comparison (this probably requires a linear scan of the database to
 discover any blocks with such revisions, but the amortised cost is low).
 Increasing the type size would require a change to users of this method,
 as would a custom comparison for any which want an ordering of revision
 numbers.

 Thoughts?

--
Ticket URL: <https://trac.xapian.org/ticket/709#comment:10>
Xapian <//xapian.org/>
Xapian