[Top][All Lists]

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

Re: [Gnumed-devel] Movve to Qt (was: Conference)

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Movve to Qt (was: Conference)
Date: Sun, 24 Aug 2003 11:50:30 +0200
User-agent: Mutt/

> Ok. I checked out a copy of the CVS repository. Where are the install
> instructions?
There's no real need to install. You should be able to run
GnuMed right from the CVS tree. ->
cd gnumed/gnumed/client/wxpython/

> Do I just send you the requirements file to be added to CVS?
One way.

> While I'm
> asking this, what's the procedure to gain CVS access? Meritocracy?
Get an account at Upload an SSH public key.
Make us add you to the gnumed developers list on savannah.

> > Can a good case be made *against* using NOT NULL constraints
> > on table attributes in audit trail tables where the
> > corresponding attributes in the audited table also have a NOT
> > NULL constraint ? OR is it (and for what reason) important to
> > not have ANY constraints on audit trail tables ? We are doing
> > the NOT NULL in audit trail tables currently as I feel the
> > need to be as strict as possible about the data BUT i'd

> The data model should be a truth table of your business rules.
I am not talking about business rules. This is about auditing
changes. The business rules only apply indirectly.

> According to the
> relational model, nothing should ever be NULLable.
We are writing software against the good-enough de-facto
standard SQL, not the relational model.

> However, in audit trail tables we know where the data is coming from (if
Do we ? That is the big question. And even if we do we don't
necessarily know the quality of it. That is my point: Can it
happen that unclean data is coming from the triggers into the
audit tables ? That would mandate not using NOT NULL. I don't
want to "save extra checks" because I "know the data is valid".
I wonder if it is worthwhile to add the NOT NULLs to the audit
trail tables since whatever comes their way may not be null
except in very horrible lossage which one would like to know
about ASAP, and be it by way of the auditing triggers failing.
I am not concerned about the syntactic validity of the data in
the audit trail. If there's crap in the audited table I want
to audit the crap.

> Yes, it would be easier, but thinking about it for just a little bit,
> would it really be that much easier? You could write a function/method
I could but I would also have to do so. And that's the point
here. It's been done in gmAuditSchemaGenerator by now anyways
(w/o NOT NULLs).

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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