| Age | Commit message (Collapse) | Author |
|
By using an enum we can have better error detection than copy pasting
key strings around.
The question of what layer this belongs in is a bit
tricky. Historically most of the keys are defined by the CLI. On the
other hand features like excludes are supported in the
library/bindings, and it makes sense to configure them from the
library as well.
The somewhat long prefix for notmuch_config_t is to avoid collisions
with the existing usage in notmuch-client.h.
|
|
Fill in the remainder of the documented functionality for
n_d_open_with_config with respect to config file location. Similar
searching default locations of the database file still needs to be
added.
|
|
Initially document the intended API and copy the code from
notmuch_database_open_verbose. Most of the documented functionality is
not there yet.
|
|
The main goal is to allow configuration information to be temporarily
overridden by a separate config file. That will require further
changes not in this commit.
The performance impact is unclear, and will depend on the balance
between number of queries and number of distinct metadata items read
on the first call to n_d_get_config.
|
|
This will be used (and tested) by the configuration caching code to be
added in the next commit.
|
|
If Xapian has thrown an exception, it is not safe to invoke the
destructor when freeing the list struct.
(cherry picked from commit 43ba5ed7eca6e9f6433b8c2c2a9d834d4101b92a)
|
|
Reduce the size of database.cc, and prepare for extending the database
opening API
|
|
If Xapian has thrown an exception, it is not safe to invoke the
destructor when freeing the list struct.
|
|
Reduce the size of database.cc, and limit the scope of prefix_table,
make sure it's accessed via a well-defined internal API.
|
|
database.cc is uncomfortably large, and some of the static data
structures do not need to be shared as much as they are.
This is a somewhat small piece to factor out, but it will turn out to
be helpful to further refactoring.
|
|
As diagnosed by Olivier Taïbi in
id:20201027100916.emry3k2wujod4xnl@galois.lan, if an exception is
thrown while the initialization is happening (e.g. if the function is
called on a closed database), then the destructor is (sometimes)
invoked on an uninitialized Xapian object.
Solve the problem by moving the setting of the destructor until after
the placement new successfully completes. It is conceivable this might
cause a memory leak, but that seems preferable to crashing, and in any
case, there seems to be nothing better to be done if the
initialization is failing things are in an undefined state by
definition.
|
|
|
|
Use `makefile-gmake-mode' instead of `makefile-mode' because the
former also highlights ifdef et al. while the latter does not.
"./Makefile.global" and one "Makefile.local" failed to specify any
major mode at all but doing so is necessary because Emacs does not
automatically figure out that these are Makefiles (of any flavor).
|
|
Also mention error return in API docs
|
|
Falling out of the catch meant the error return was lost
|
|
Also clarify API in error case.
|
|
Also clarify API in error case.
|
|
This is a rare and probably serious programming error, so better not
to silently return a default value.
|
|
static_cast is a bit tricky to understand and error prone, so add a
second pointer to (potentially the same) Xapian database object that
we know has the right subclass.
|
|
The plan is to change the underlying representation.
|
|
I'm not sure what the point of modifying that right before destroying
the object is. In a future commit I want to remove that element of the
object, so simplify that task.
|
|
The catch block either needs to return, or the function needs to
return "status". Choose the latter for consistency with
n_d_get_config.
|
|
The error message and name were confusing when called in some "read
only" context.
|
|
The API docs promise to handle relative filenames, but the code did
not do it.
Also check for files outside the mail root, as implied by the API
description.
This fixes the bug reported at
id:87sgdqo0rz.fsf@tethera.net
|
|
Also clarify documentation of error return from n_d_needs_upgrade.
|
|
notmuch_database_get_version previously returned 0 on some errors, but
did not document this. Luckily 0 is not a valid database version.
|
|
In order to mimic the "best effort" API of Xapian to provide
information from a closed database when possible, do not
destroy the Xapian database object too early.
Because the pointer to a Xapian database is no longer nulled on close,
introduce a flag to track whether the notmuch database is open or not.
|
|
The original generic handler had an extra '%s' in the format
string. Update tests that failed to catch this because the template to
print status strings checked 'stat', which was not set.
|
|
Also update the documentation for the behaviour of n_m_get_thread_id
that this fix relies on.
|
|
At least the exception we already catch should be reported properly.
|
|
Initially the new function is mainly tested indirectly via the
wrapper.
|
|
This passes the NULL return inside _ensure_maildir_flags does not
break anything. Probably this should be handled more explicitely.
|
|
This adds one more reason why _notmuch_thread_create might return
NULL, but those were not previously enumerated, so no promises are
broken.
|
|
As a side effect, we revert the switch from notmuch_bool_t to bool
here. This is because those two types are not actually compatible when
passing by reference.
|
|
It's not very nice to return FALSE for an error, so provide
notmuch_message_get_flag_st as a migration path.
Bump LIBNOTMUCH_MINOR_VERSION because the API is extended.
|
|
Currently I don't know of a good way of testing this, but at least in
principle a Xapian exception in _notmuch_message_{add,remove}_term
would cause an abort in the library.
|
|
The churn here is again mainly re-indentation.
|
|
This is mostly just (horizontal) code movement due to wrapping
everything in a try / catch.
|
|
This will require some care for the caller to check the sign, and not
just add error returns into a running total.
|
|
This allows the function to return an error value rather than
crashing.
|
|
This should not change functionality, but does slightly reduce code
duplication. Perhaps more importantly it allows consistent changes to
all of the similar exception handling in message.cc.
|
|
This function catches Xapian exceptions. The test is intended to make
sure it stays that way.
|
|
This is essentially copied from the change to notmuch_message_get_filename
|
|
This is the same machinery as applied for
notmuch_message_get_{thread,message}_id
|
|
We need to to set a query and retrieve the threads to meaningfully
test this function.
|
|
This is just for consistency, and a small reduction in the amount of
boilerplate.
|
|
This will be mandatory as of Xapian 1.5. The API is also more
consistent with the FieldProcessor API, which helps code re-use a bit.
Note that this switches to using the built-in Xapian support for
prefixes on ranges (i.e. deleted code at beginning of
ParseTimeRangeProcessor::operator(), added prefix to constructor).
Another side effect of the migration is that we are generating smaller
queries, using one OP_VALUE_RANGE instead of an AND of two OP_VALUE_*
queries.
|
|
The old API was deprecated in Xapian 1.3.4 and (will be) removed in 1.5.0
|
|
This allows us to return an error value from the library.
|
|
By catching it at the library top level, we can return an error value.
|