gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] jl-gui et alii


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] jl-gui et alii
Date: Mon, 19 Aug 2013 10:55:14 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Aug 19, 2013 at 10:10:07AM +0200, Karsten Hilbert wrote:

> I see that you've published quite some code on gitorious
> which is both impressive and really nice to see.
> 
> I would suggest that the first step for inclusion would be
> to get the database requirements of your code transferred
> somehow. This might be an achievable goal for 1.4.
> 
> Can you walk me through the database changes you have done
> along with the rationale for each (not for WHY you have done
> something in particular -- that's clear: because you needed
> to --  but rather for why you did it the way you did) ?

I had a quick look. One thing I noticed is this:

commit 15b180028134ac98796558eb794b16f246e8faea
Author: Jerzy Luszawski <address@hidden>
 Date:   Tue Jul 16 03:30:01 2013 +0200

    small fix to avoid errors in v19-dem-praxis_branch-static.sql

diff --git 
a/gnumed/gnumed/server/sql/v18-v19/static/v19-dem-praxis_branch-static.sql 
b/gnumed/gnumed/server/sql/v18-v19/static/v19-dem-praxis_branch-static.sql
index e9f500f..13c9223 100644
--- a/gnumed/gnumed/server/sql/v18-v19/static/v19-dem-praxis_branch-static.sql
+++ b/gnumed/gnumed/server/sql/v18-v19/static/v19-dem-praxis_branch-static.sql
@@ -5,6 +5,8 @@
 -- Author: address@hidden
 --
 -- ==============================================================
+\unset ON_ERROR_STOP
+drop table dem.praxis_branch cascade;
 \set ON_ERROR_STOP 1
 
 -- --------------------------------------------------------------


This is questionable (not in general, not for you or in your
case but in the context of *standard* bootstrapping GNUmed
databases -- which is what we need MOST people to do or else
there's no chance we can help them with problems). Here is
why:

*-static.sql files are assumed to be run only ONCE on the
unadulterated previous database schema version. If that
fails it must be run against the previous version again
after fixing the problem.

Tables only get created once. If they already exist when
they are created there is two sources of that error:

1) Someone has modified the schema manually previously.

        Solution: The change needs to be taken back elsewhere.

2) The *-static.sql script is faultily assuming the
   table should not exist.

        Solution: In that case THAT assumption needs to be
        corrected and the *-static.sql needs to become a
        *-dynamic.sql and modify the existing table
        appropriately. The reason is that people cannot lose
        data from the existing table which they do if it is
        simply dropped.

Given that said table did not yet exist in standard
gnumed_v18 it must have existed in *your* gnumed_v18 which
means your gnumed_v18 is not standard (we knew that
already). This is, of course, OK !  You are not obliged to
run a standard database. In fact, your enhancements can only
work if you do not, I understand that.

The rationale for not dropping the table is this:

Assume someone enhanced gnumed_v16 to support praxis
branches in a dem.praxis_branch table *independant* of "us"
and, also, did not tell us about it. Then - upon upgrade -
we would simply delete data they had collected !  This is
something I'd like to avoid.

Imagine it had been yourself: You *are* likely to develop
enhancements. You *do* understand the conventions of GNUmed
so you *are* likely to have named a table dem.praxis_branch
in your database.

Let's find a better solution.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



reply via email to

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