Re: [Gnumed-devel] run_commit2()

[Ian Haywood]

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