tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Williams <kevin...@qwest.net>
Subject Re: [DAS] Erroneous behavior when PK's value is updated using applyChanges()
Date Wed, 04 Apr 2007 18:43:54 GMT
I think allowing changes to PK columns would be a mistake.

Brent Daniel wrote:

> Amita,
>
>  I think we intended to not allow any updates to the primary key
> field. If we do want to allow this, I would suggest that the fix is to
> have the UpdateGenerator use the old value of the PK field for the
> where clause rather than the current value. That way you would get
> something like "update ORDERDETAILS set ORDER_ID=10 where ORDER_ID = 1
> and ORDER_ID = 1". The duplication is inefficient, but shouldn't
> matter.
>
> Brent
>
> On 4/4/07, Amita Vadhavkar <amita.vadhavkar@gmail.com> wrote:
>
>> Hi All,
>>
>>
>> In addition to the problem mentioned in below link,
>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16304.html
>>
>> Found one more issue when tried to have a PK on the same table
>> OrderDetails{ORDER_ID, PRODUCT_ID, PRICE} , PK - ORDER_ID
>> And update is attempted to update ORDER_ID to a new value (1->10) using
>> applyChanges().
>>
>> Now the scene in UpdateGenerator.getUpdateCommand(), takes into 
>> account the
>> PK list
>> (which is not zero now) and forms a update statement as
>>
>> update ORDERDETAILS set ORDER_ID = ? where ORDER_ID = ?  and ORDER_ID 
>> = ?
>>
>> Here in the where clause - 2nd ORDER_ID param is marked as collision 
>> param
>> but
>> first ORDER_ID param is not.
>>
>> Due to this, in ChangeOperation.execute(), the 1st ORDER_ID param in 
>> where
>> clause calls
>> setValue() and 2nd ORDER_ID param in where clause does not (as its
>> collision).
>>
>> So the final statement becomes:- e.g.
>>
>> update ORDERDETAILS set ORDER_ID = 10 where ORDER_ID = 10 and 
>> ORDER_ID = 1
>>
>> This results in "An update collision occurred "-
>> OptimisticConcurrencyException.
>>
>> To avoid this problem, in UpdateGenerator.getUpdateCommand(), in the 
>> PK list
>> iteration
>> part, we need to check for collision, as we are checking in the later 
>> code
>> and set value
>> of the param in where clause, if collision is the case indeed.
>> Or have additional intelligence in the update generation logic to avoid
>> where clauses
>> like where ORDER_ID = ?  and ORDER_ID = ? , by omitting duplications
>>
>> Please let me know what is a right approach and if it needs a 
>> JIRA+patch.
>>
>> Regards,
>>
>> Amita
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


Mime
View raw message