gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] permsssions needed for gmClinicalRecord to work


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] permsssions needed for gmClinicalRecord to work
Date: Sun, 26 Oct 2003 19:58:19 +0100
User-agent: Mutt/1.3.22.1i

> Most of the problems at the moment is that gmPG 
> with its  dumb "run_query
> returns false  if error , makes things easier for the programmer " idea 
> won't tell me what exception
> the driver's were throwing, so I had to modify it to print out a 
> traceback (the log files weren't telling me, for some reason), and most 
> of the errors so
> far are "permission denied."
Now, there's

run_query()
 which takes a cursor, a query and arguments and gives you the
 most control over the whole transaction

run_ro_query()
 which takes a service name (fast since cached connections), a
 query, args and will give you the result and optionally the
 column order by name, this will default to RO conns

run_commit()
 which takes a service name (slower, not cached) and a list of
 query/args tuples, if the last query returns rows it will
 return those (good for accessing OIDs/PKs after INSERTs),
 this will default to RW conns and commit if not detecting any
 errors

Neither of these are shy about their actions. They report errors
and exceptions. If --debug was on the command line you'll get
more info than you care to look at. If that isn't enough (and
you are using pyPgSQL) you can switch on processed query
printing from inside the DB adapter in gmPG. And if you are
really desperate we can make that an option with the above
functions. Please report the *bugs*. Original exception type
and message will get logged with at least lWarn.

> denied errors). Will someone else write the gmClinicalRecord methods to 
> translate the widget map values , or
gmClinicalRecord will not contain methods that correspond to
widget entry fields, conceptually. The widgets have to figure out
which of the methods they need to call. gmClinicalRecord
provides (currently insufficient amounts of) methods at a clinically
meaningful granularity if I have any say.

> can I do some ?
Certainly.

> Or do you want the map values to have some validation /or 
> re-organization on the editarea side?
IMHO, things like dates should be returned by, say,
gmDateInput validated according to the rules and bounds set up
at gmDateInput creation.

> Or if anyone thinks what I'm doing now is a waste of time
No.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

[Prev in Thread] Current Thread [Next in Thread]