Karsten Hilbert wrote:
>> Of course that's not a good thing, but we'd rather have a basic functional >> client, >> then go back and add these features (even if it means a rewrite) > Well, the current database schema does not prevent you from > ignoring row locking and concurrency. You could *just write* > a client ignoring those issues and still store data in the > same schema. The rub of it is not the "ignoring" part but > rather the "just write" part. Point taken. However you seem to be solving this 3 ways at once: 1- recieving NOTIFY events to reload widgets 2- using SELECT .. FOR UPDATE 3- checking xmin on UPDATE and DELETE Why all 3? (I'm sure there's a good reason, I just can't figure it out) > That is a misconception. However, it may very well be > sufficient to put a wrapper around them which handles them > in an invisible, default way such that you don't have to > worry about them. As if they were not there. But they are > still handled. Just that you don't have any control over > them. How to encapsulate cleanly is the big issue. >>> 2) where is the *result* as it is inefficient ? >> look at the demographics code, personally I find it's a nightmare, >> I mean no insult, the design errors I'm talking about are mostly mine. >> [And the refusal to delete my old unused code is just infuriating. >> we're using CVS for god's sake: we can always get it back!] > > Look at client/gmDemographicsWidgets.py again :-) Ok, thanks. The code is now very garrulous, but at least sane. ian _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
