[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] run_commit2()
From: |
Ian Haywood |
Subject: |
Re: [Gnumed-devel] run_commit2() |
Date: |
Tue, 2 Nov 2004 12:36:15 +1100 |
On Tue, 2 Nov 2004 00:21:13 +0100
Karsten Hilbert <address@hidden> wrote:
> Hi all,
>
> I have added a def run_commit2() stub with a detailed
> docstring on the intended API. This is to slowly replace
> run_commit() which works but suffers some ugly warts
> which we try to avoid this time.
My biggest criticism of run_commit is that it establishes a new
read-write *connection* for every call (unless you manually create connections,
however IMHO the main purpose of this function is to avoid having to do that)
Can we pool read/write connections as we do for read connections?
Even better, throw queries which have no result
[which, with use of of a subquery like "(select curr_val
('the_table_just_inserted_pk_seq'))", would be most],
onto a queue so a background thread can commit them
> <end_tx>
> - controls whether the transaction is finalized (eg.
> committed/rolled back) or not, this allows the
>
> <max_tries>
> - controls the number of times a transaction is retried
> after a concurrency error
These are good ideas.
> - returns a tuple (status, data)
> - <status>:
> * True - if all queries succeeded (also if there were > 0
> queries)
> * False - if *any* error occurred
I still don't understand why we can't throw a python exception for database
errors.
(IOW, the function would always return the data), this makes the calling code
much cleaner.
AFAICT there are 5 types of error, so 5 classes of exception:
1 - bugs in the query
2 - loss of connection or other backend catastrophe.
3 - integrity constraint violation
4- access violation
5 - concurrency
5 you have covered, for the others the client action is nearly always the same:
dump to the log (which run_commit already does)
and display an error dialog, which can be done by a single except: clause in
the GUI event handler, using a message supplied in the
exception.
For 1,2 and 4 run_commit can generate an error message itself, for 3 you would
need to provide with the query, so <queries>
would be a list of (query, [args], error_message)
I'm sure there are occasions where we do need specific action in response to
errors, but a try..except clause is much easier
than surrounding *every* call to run_commit with "if/else", just to do the same
thing on error 90% of the time, additionally excepts need
only catch the error type you are looking for.
Ian
--
PGP public key E750652E at wwwkeys.pgp.net
9BF0 67B7 F84F F7EE 0C42 C063 28FC BC52 E750 652E
pgpQ9AZuKiJVY.pgp
Description: PGP signature