[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/

> 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

> >>> 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;
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

> >>>  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;
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.

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.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

[Prev in Thread] Current Thread [Next in Thread]