I've been working on some function to recover from collisions (since at the moment we have none :) ). One of the recovery mechanisms I'm planning to put in is a means to "force" the update. Though it would require an extra step, this should take care of this case.
Brent On 10/17/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
I have talked to clients that want their data slammed into the database no matter what. But, this is an edge case. We can wait for someone to ask for it ... or contribute it. Brent Daniel wrote: > 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] > > > > --------------------------------------------------------------------- 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]
