Re: Packaging VistA - environments
On 07/11/2012 02:42 AM, Karsten Hilbert wrote:
But unlike PostgreSQL,
VistA environments may be chained and you can have trees of
environments.
Can you expand on "chain" and "trees" a little bit ?
[KSB] Sure.
Explaining the routine part is pretty simple. The VistA distributed as
part of a Debian package will have 25000 or so routines (give or take a
few thousand depending on the VistA flavor). Let's call this A. A site
decides to implement VistA, but wants to do some customization for
scheduling and lab. So, they create a development environment B. There
is no need to copy all of the 25000 routines. They create an environment
B. Processes running in environment B have a gtmroutines environment
variable that gives them a routine search path of (B,A). So, any
customization routines for scheduling and lab go into B, and processes in
B will find these routines earlier in the search path than routines with
the same names in A, but for routines that are not in B will find the
routines as distributed in A. Now, they may further separate the
development for scheduling and lab by creating an environment C for
scheduling and D for lab (in other words B becomes an integration
environment rather than a raw development environment). So, the routine
search path for scheduling development becomes (C,B,A) and that for lab
becomes (D,B,A).
Now, if they hire Karsten and Bhaskar as programmers to work on
scheduling, we may choose to work in our own development sandboxes,
environments E and F respectively. So Karsten may use (E,C,B,A) and
Bhaskar may use (F,C,B,A) as their search paths. Or, since they are
collaborating on development, they Karsten may set his gtmroutines search
path as ((E,F),C,B,A) and Bhaskar may set his as ((F,E),C,B,A).
Periodically, they will push routines from E and F to C. The hospital
will eventually push routines from C to B.
After customization is complete, the hospital may create an acceptance
testing environment G, as a copy of B. These processes will use a search
path of (G,A).
For databases, it is slightly different. Each environment defaults to a
copy of the database from its parent environment (e.g., B will start with
a copy of A's database, C defaults to a copy of B and so on). But
databases can be shared, again with different environment variables and
GT.M configuration. So, in the example above, Karsten and Bhaskar may
choose to share a common database, even while having slightly different
search paths for routines. Or, for example, all the above environments
may map the part of the database pertaining to drugs to a common "drug
file" to which they all have just read-only access. The drug file may be
periodically updated as part of a formulary change, and everyone will
then refer to the same formulary.
Regards
-- Bhaskar
Karsten
--
GT.M - Rock solid. Lightning fast. Secure. No compromises.
_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
Reply to: