Date: Sat, 17 Jan 2015 15:12:05 +0000
From: Gaute Hope <eg@gaute.vetsj.com>
Subject: Re: DatabaseModifiedErrors causing troubles
To: David Bremner <david@tethera.net>, notmuch <notmuch@notmuchmail.org>
References:
 <CABKe4MvEdcsq8BZ-vq6R0Vnw87zEgBvqW_2F-Wysf5GNchqweg@mail.gmail.com>
	<87bnmkgr57.fsf@maritornes.cs.unb.ca>
	<1421493070-astroid-1-4x8pflg7mc-1327@strange>
	<87fvb9bnf8.fsf@maritornes.cs.unb.ca>
In-Reply-To: <87fvb9bnf8.fsf@maritornes.cs.unb.ca>
User-Agent: astroid/vv0.1-42-ge9d4344b (https://github.com/gauteh/astroid)
Message-Id: <1421507092-astroid-4-sde37j1ij5-1327@strange>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Precedence: list

Excerpts from David Bremner's message of January 17, 2015 13:29:
> Gaute Hope <eg@gaute.vetsj.com> writes:
>
>>
>> Hi David,
>>
>> Would it be possible with an error code that I could compare against in
>> stead? It would then work a bit like a global instance of the gmime
>> error. It could even be a preparation step against a gmime-error-style
>> solution in the far future.
>>
>> I am sure you know all the bad reasons for using a strcmp with strings
>> such as small (subtle) changes making them useless or future
>> localization of notmuch. This solution is in my opinion worse than the
>> current situation, it will lock things in and create problems for future
>> API compatability and application maintainers. I would rather wait for
>> or spend some time on a more general solution.
>
> I don't agree it's worse than the current situation but I take your
> point it isn't ideal.  We could do some kind "errno" in the database
> structure.  I think there are not that many functions with this
> unhelpful error return type. Based on a scan of notmuch.h, I see
>
> notmuch_query_search_threads
> notmuch_query_search_messages
>
> and the two count functions that I already posted API breaking patches
> for.  It might be better just to update the API (either adding versions
> with error returns, or just forcing people to change) for these
> functions.  Otherwise we have two different ways of returning status
> codes, and the "errno" is only used some of the time.

Yeah - a consistent way of doing this would in my opinion be very
useful. Also, many other functions could be affected by outside
processes as well (notmuch new, notmuch tag) that do not necessarily
violate the thread-safety restrictions on xapian / notmuch. Errors in
these functions, and importantly which error, are currently hard to
catch and identify (say notmuch_messages_move_to_next). The same error
reporting system could be used for these. With a flexible error system
we could fix these as they are discovered.

Cheers, Gaute

=