You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Amita Vadhavkar <am...@gmail.com> on 2007/04/04 14:00:35 UTC
[DAS] Erroneous behavior when PK's value is updated using applyChanges()
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
Re: [DAS] Erroneous behavior when PK's value is updated using applyChanges()
Posted by Kevin Williams <ke...@qwest.net>.
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 <am...@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
Re: [DAS] Erroneous behavior when PK's value is updated using applyChanges()
Posted by Brent Daniel <br...@gmail.com>.
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 <am...@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