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]