Re: [Gnumed-devel] Comments on 0.2.......................

[Ian Haywood]

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