[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] re: comm_channel
From: |
catmat |
Subject: |
Re: [Gnumed-devel] re: comm_channel |
Date: |
Wed, 02 Feb 2005 18:59:19 +1100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 |
Ian Haywood wrote:
Unfortunately, Syan, if you create views for your own client
(which of itself is fine), you will be primarily responsible for
keeping them up-to-date with the rest of the schema, or, at least,
keeping
a close eye on schema changes.
not sure if you were trying to be nice by changing a view you don't use
, or not.
Moving to an outer join should be the fix. (so non-existent comms are
NULL)
why not keep the original working view (that you don't use), just
remove the join to comm_channel and rename identity2_comm_channel ? ( so
your batch setup will run?)
To do a full outer join doesn't look much better than a cross join
across comm types and then an inner join, only conceptually it might be
easier to understand.
The main reasons are that 1) joins don't allow duplicate named
columns, so you would have to select and rename each column from each
lnk_identity2comm table joined;
and 2) you have to have the id_identity fields included to join on, and
they would have to be different named to,
then you would have to select again to remove those redundant
id_identity fields to come up with a nice looking
view.
BTW , briefly looking at the changes (at work),
you made gmCurrentPatient accept a patient object instead of
the patient id in its constructor ( which is really just a setter
method) , and moved the responsibility for retrieving the patient out of
gmCurrentPatient.
Good idea, so it means gmCurrentPatient can potentially switch patients and
not care whether they are in memory or retrieved. This means you can now
have multiple patient objects lying
around in memory, and you don't have to retrieve them everytime. This
also makes it easier to have a multi
patient user interface , if it were wanted, or a faster responding web
business end server ( or make it possible
just to switch user context, so you don't have to have idle backend
processes bound to idle users).
Not sure about naming cIdentity inheriting from cOrg, but the logic is
ok : the yanks ( damn their patents)
have used Party as the superclass of person and orgs, and put the shared
functionaliy in there
(addressability, contactibility)