Kevin,
We can do that, but it will be our fourth different way to specify
OCC behavior (default, version column, managed version column, and
none.) Is there a good use case for this? It seems like the only time
you would want to go without concurrency control is when you have
read-only tables, and in that case this behavior would never be
reached anyway.
Brent
On 10/17/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
Brent,
This sounds reasonable but we probably want some mechanism to provide our previous
default policy which is "no collision checking". Maybe a piece of config. What
do you think?
--
Kevin
[DAS] Use overqualified update by default
-----------------------------------------
Key: TUSCANY-866
URL: http://issues.apache.org/jira/browse/TUSCANY-866
Project: Tuscany
Issue Type: New Feature
Components: Java DAS RDB
Reporter: Brent Daniel
Currently in the DAS we either use a user-defined version column or do not use any concurrency control. We
have enough information to build an overqualified update in cases where a version column is not defined. For
example, if a field "name" is changed from "Bob" to "John", we would generate a
query such as:
UPDATE CUSTOMER SET NAME = 'John' WHERE ID = 1 AND NAME = 'Bob'
If the statement does not update any rows in the database, the DAS will throw a
concurrency control exception.
This scheme will not work in case of LONG VARCHAR, BLOB, or CLOB columns, so an
exception should be thrown in that case indicating that a version column must
be defined.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
