Re: [Gnumed-devel] re: create identity ( yet again).

[Karsten Hilbert]

> 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