Re[2]: [GNUe] cascade insert into master detail

[Oleg Noga]

Hello Reinhard,

Thanks a lot!

I can't use oids due to database layer design. (All queries going
thrue stored functions).
I think that calling counter before insert with explicite id is
stress-safe. Even when client makes this work.
I am going to make it in stored procedures and return primary key of
new inserted row to client.
Then client will use this primary key to update details.

-- 
Best regards,
 Oleg                            mailto:address@hidden



    ----- Original Message -----
    From: Reinhard Mueller <address@hidden>
    To: Oleg Noga <address@hidden>, address@hidden
    Date: Monday, December 10, 2007, 3:29:12 PM
    Subject: [GNUe] cascade insert into master detail

RM> Hi, Oleg!

RM> Finally I had the time to look into this.

RM> Am Dienstag, den 04.12.2007, 19:17 +0200 schrieb Oleg Noga:
>> When i am only inserting new spr_user row it is ok.
>> When i am only inserting new spr_usergroup row it is ok.
>> When i am trying to insert a user with newly entered group list i have
>> exception:

RM> You are using Posgres, which doesn't have OIDs for user tables by
RM> default.

RM> So whenever you insert a new master record, the Postgres server assigns
RM> it a new user_id on its own. The client (gnue-forms) has no way of
RM> finding out what user_id the newly inserted record got. So gnue-forms
RM> also has no way of setting that user_id in the detail records.

RM> If you enable OIDs, Postgres tells gnue-forms about the OID of the newly
RM> inserted record, and gnue-forms can query the record again using that
RM> OID and find out about the user_id assigned.

RM> To enable OIDs, you have to:

RM> 1. CREATE TABLE ......... WITH OIDS;
RM> 2. have "use_oid = yes" in your connections.conf

RM> I have tried it, and it works if you do it that way.

>> What is 'rowid' datasource attribute?

RM> Please forget about that attribute, it will soon be deprecated.

>> How datasource behaviour depends on primarykey, primarykeyseq and
>> rowid attributes defined or not?

RM> primarykey: will be used to find a record again after it has been
RM> changed. Gnue-forms relies on the assumption that the primary key of a
RM> record never changes through triggers or stored procedures. This concept
RM> fails for newly inserted records if the primary key is set from a
RM> sequence (see above). If a rowid is available, it is preferred over the
RM> primary key, since the rowid is guaranteed to *never* change.

RM> primarykeyseq: name of a sequence. If set, the client (gnue-forms) will
RM> query that sequence from the database and directly set the primary key
RM> of a newly inserted record before posting it. This is a workaround for
RM> exactly your problem, but it is very ugly: it moves stuff to the client
RM> that should happen at the server. I recommend to avoid this at any cost.

RM> Thanks,
RM> Reinhard