The retrying forever is asynchronous from the control logic thread, but will stop all other queries from going through until it succeeds. Callbacks are totally doable if you're happy to work with them, but I think it'd be overcomplicating things.
I'm now leaning toward retrying everything twice, then raising an error for all queries - it's consistent, simple, and error handlers are easy to use. This does mean the control logic thread would have to block while writes went through, but it's probably worth it I think. It already has to block for the reads anyway.
In terms of the features without justification thing, yeah I totally agree, but I am also trying to make provision for the software to go in other directions in the future when I don't have the time to keep changing it - we've ended up modifying a lot of stuff in the past because of new ideas, and I'd rather do the work now if we can figure out what we might want later.
Database Code: Reporting Query Failures
Re: Database Code: Reporting Query Failures
That all sounds reasonable. If 'retry forever' blocks subsequent queries, then I suppose it has much less advantage over 'retry n times'. If 'retry n times' is therefore preferred, then I suppose it makes sense to have n as a parameter, because it is hard to know the best value for n right off the bat, and we might want to change n later on if experience shows it is better off being a larger or smaller number.
Re: Database Code: Reporting Query Failures
Okay, all done.
It ended up being more complicated than I wanted, but it works
It ended up being more complicated than I wanted, but it works
Hamish