As I have said in the note, these where the scenarios which first popped in
my mind. Give me until Saturday to sort things out - things may be not as
ugly as they look.
-----Original Message-----
From: Andrus Adamchik [mailto:andru..bjectstyle.org]
Sent: Wednesday, October 23, 2002 6:45 PM
To: Shengaout, Misha (MARC)
Cc: cayenne-deve..bjectstyle.org
Subject: Re: Stored Procedures Support
Looks pretty ugly. Makes me wonder if O/R is appropriate for such things at
all?
Will keep thinking...
Andrus
Shengaout, Misha (MARC) writes:
> I should be able to provide several scenarios by e.o.d. Saturday. For now,
> here are couple crude cases:
>
> 1. Entities INSURANCE_CLAIM and INSURANCE_CLAIM_RECORD have one-to-many
> relationship. Class InsuranceClaimRecord has field "workflowStatus", which
> is determined as the result of the very complex query. Consequently, to
> retrieve the collection of InsuranceClaimRecord-s for the claim we are
using
> spLoad_Claim_Detail(vrClaim_ID As NUMBER), which returns the result set
> including INSURANCE_CLAIM_RECORD table and "WORKFLOW_STATUS". There is no
> stored procedure for retrieving the INSURANCE_CLAIM one at a time using
ID.
> 2. spMy_Inbox_Claims(vrUser_ID As NUMBER) returns the tabular, read-only
> record set based on INSURANCE_CLAIM with the results of the search. When
> user selects the row in the table, the insurance claim is opened for
> editing. Ideally we would have one-to-one relationship, which would allow
to
> navigate easily from MyInboxInsuranceClaim to InsuranceClaim.
> 3. When creating new InsuranceClaimRecord, we have to generate associated
> workflow items, which is done by calling corresponding stored procedure
(too
> complex to be done through trigger). Need the event, which would allow to
> add this call for the CREATE event in the same transaction frame.
> 4. When creating new InsuranceClaim results in generating of the
> corresponding workflow, which is encapsulated in spClaim_InsUpd(). This
> stored procedure has the set of fields matching INSURANCE_CLAIM table, and
> does all the workflow generation. Moving it to the trigger is not possible
> for various reasons, so all INSERT and UPDATE operations for
InsuranceClaim
> should be done using spClaim_InsUpd() stored procedure, with the fields of
> the class mapped to the fields of the sp. The generated ID is always
> returned in the OUT recordset.
>
> That's it for now. Shoould polish it over the next couple days.
>
This archive was generated by hypermail 2.0.0 : Wed Oct 23 2002 - 18:51:06 EDT