using the Nacos2.2.2 and kingbase8 database update config conflit whit DuplicateKeyException

[justimaging]

I am using kingbase8 database and my datasource plugin for nacos 2.2.2，when i update the config ,i occur caused: PreparedStatementCallback;错误: 重复键违反唯一约束"uk_configinfo_datagrouptenant"

[KomachiSion]

see #10044 and #10045

[YunWZ]

The intent of these statements is: Try { INSERT NEW CONFIGURATION } catch (DKE - this means that the configuration exists, so the same configuration needs to be updated. And we only need to update the existing configuration!).

DuplicateKeyException thrown when an attempt to insert or update data results in violation of a primary key or unique constraint.

DataIntegrityViolationException thrown when an attempt to insert or update data results in violation of an integrity constraint.

There are many scenarios where data constraint exceptions will occur, such as: the field is not empty

BTW we can't update an unexist cofnig!

[YunWZ]

If there are two "same" configurations in your database, check your config table DDL, do these two records have the same key or unique key?

[yanjinzh6]

missing sql-error-codes.xml for kingbase8?

[KomachiSion]

@YunWZ I see the DataIntegrityViolationException and DuplicateKeyException commend, Spring recommend to handle DataIntegrityViolationException but not DuplicateKeyException , should we revert to handle DataIntegrityViolationException?

commend in DuplicateKeyException

/**
 * ....
 * 
 * <p>Consider handling the general {@link DataIntegrityViolationException}
 * instead, semantically including a wider range of constraint violations.
 *
 * @author Thomas Risberg
 */

and commend in DataIntegrityViolationException

 * <p>Serves as a superclass for more specific exceptions, e.g.
 * {@link DuplicateKeyException}. However, it is generally
 * recommended to handle {@code DataIntegrityViolationException}
 * itself instead of relying on specific exception subclasses.

[YunWZ]

@YunWZ I see the DataIntegrityViolationException and DuplicateKeyException commend, Spring recommend to handle DataIntegrityViolationException but not DuplicateKeyException , should we revert to handle DataIntegrityViolationException?

commend in DuplicateKeyException

/**
 * ....
 * 
 * <p>Consider handling the general {@link DataIntegrityViolationException}
 * instead, semantically including a wider range of constraint violations.
 *
 * @author Thomas Risberg
 */

and commend in DataIntegrityViolationException

 * <p>Serves as a superclass for more specific exceptions, e.g.
 * {@link DuplicateKeyException}. However, it is generally
 * recommended to handle {@code DataIntegrityViolationException}
 * itself instead of relying on specific exception subclasses.

Well, that's a good suggestion, we should handle all exception cases instead of just `DuplicateKeyException.

Of course, in this case we should to do two things:

1. When catching DuplicateKeyException, we need to update record;
2. Otherwise, tell the method's caller some information (for example, throw an exception).Because users may customize their owner database plugin.

What do you think?

[KomachiSion]

Currently, handling DataIntegrityViolationException and DuplicateKeyException together, but log more inforamtion for DataIntegrityViolationException. Future might use new way to handle it like #10672