Hi Sergey, > It would be great to use the same API and use operation store() without any > suffixes. > > If we define some optimistic locking strategy in generator's configuration > (for example, use "version" column strategy), it may be applied in store() > method transparently to client.
I don't entirely agree with that. Even if you may have configured a MY_TABLE.VERSION to be the version column used for optimistic locking, you don't *always* want to apply optimistic locking on store(). E.g, some batch job updating an irrelevant column might want to perform this update, no matter how many times the same record was updated by users in the mean time. However, I guess that in those cases, storeLocked() could automatically assume the behaviour you suggested, though. E.g. - If no version/timestamp column is defined in the codegen configuration, then storeLocked() would behave as it does right now - If a version/timestamp column is defined in the codegen configuration, then storeLocked() would use that column as you suggested
