[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] re: create identity ( yet again).
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] re: create identity ( yet again). |
Date: |
Fri, 21 Nov 2003 16:56:33 +0100 |
User-agent: |
Mutt/1.3.22.1i |
> There seems to be a problem with the create_identity as it is:
Not as I see it.
> >>> Here a nameless identity is created, given the concept that a named
> identity is a person:
>
> gnumed=# insert into identity ( dob, gender) values( now(), '?');
> INSERT 29184 1
Fine.
> >>> Here setActiveName is called, and updates v_basic_person with
> lastname and firstname only, which doesn't work.
>
> gnumed=# update v_basic_person set firstnames = 'jim' , lastnames =
> 'bloggs' where i_id = 14;
> UPDATE 0
Which is to be expected as i_id=14 won't show up in
v_basic_person - and it shouldn't, as identity where id = 14
IS NOT A PERSON. I cannot access a non-person through a filter
that I created to specifically only see *persons* in a
particularly convenient way.
> >>> However, given the 2 parameters of setActiveName , you can insert
> into the names table directly , AND
> it also appears in v_basic_person.
Surely, as one has just turned an anonymous identity into a
person.
> >>> Next, a separate call to setTitle calls update v_basic_person,
No, it calls update names.
> says the update happened,
>
> gnumed=# update v_basic_person set title = 'Mr' where i_id = 14;
> UPDATE 1
Which would then be a bug...
> >>> But viewing the v_basic_person, the title doesn't appear in view.
... if this holds true ...
> >>>> Nor is it in names table.
... which leads me to believe that the triggers for the
"updateable" view v_basic_person aren't up to the task.
> On the other hand, if you use insert into v_basic_person, providing a
> simultaneous insert of non-null values to all the
> fields concerned, you don' t have a problem
As it is intended to work this way.
> which is the model for the calls to setActiveName and setTitle on the
> gmDemographicRecord object.
Nope.
All of which leads me to believe we should rather avoid
inserts/updates into views. PostgreSQL isn't hailed as
supporting updateable views very well. They aren't really a
well-defined concept beyond the most simplistic cases. The
business objects should be hiding most of the gory details
from the API user. If not then they are poorly written.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346