Re: [Gnumed-devel] test data in tables

[Karsten Hilbert]

Richard,

> do you just mean inserting test data into the tables. 
Yes.

Preferably collected in some sql scripts, e.g.
gmClinicalTestData.sql. The current SQL script scheme is
(taking clinical tables as an example):

1) gmclinical.sql (should be gmClinical.sql)

- the tables that actually hold data
- some rules/functions used in constraints etc.
- those cannot just be dropped in a life database without
  losing data
- they may be altered without data loss to the extend
  PostgreSQL supports it

2) gmClinicalViews.sql

- views, indices, rules, functions
- those can safely be dropped and recreated on a life database
  without risking any loss of data

3) gmClinicalData.sql

- default values in tables such as encounter type names,
  next-of-kin nouns, allergy type names, translations etc.
- these should always get imported when bootstrapping a fresh
  database system
- they should *not* be imported when setting up new databases
  for migration of data (because the migrated data will
  already contain the values)

4) gmClinicalTestData.sql

- this is it, Richard
- actual (but fake) data on fake patients

Of course, the boundaries are somewhat fuzzy here and there,
especially between 1) and 2).

> If so I'm more than happy to 'make up a patient and their data'
Exellent !

> if you will fend my questions
Sure. Fire ahead.

> and make sure initially I have the appropriate tables in my 
> database. I guess the bootstrap process will do that?
Correct. The public database should always be available to
serve as an up-to-date schema reference. If not, give me a
wake-up call.

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