Hi, for user concurrency we are implement a predicate. Our database in mysql is using timestamp with 3 digits of precision.

Our class:

private class OrderConcurrencyFilterFactory :
    IConcurrencyPredicateFactory
        {
            public IPredicateExpression CreatePredicate(
                ConcurrencyPredicateType predicateTypeToCreate, object containingEntity)
            {
                var toReturn = new PredicateExpression();
                var compta = (ComptadorEntity)containingEntity;

                switch (predicateTypeToCreate)
                {
                    case ConcurrencyPredicateType.Delete:
                        toReturn.Add(ComptadorFields.Lastupdate== compta.Fields.GetDbValue((int)ComptadorFieldIndex.Lastupdate));
                        break;
                    case ConcurrencyPredicateType.Save:
                        // only for updates
                        toReturn.Add(ComptadorFields.Lastupdate == compta.Fields.GetDbValue((int)ComptadorFieldIndex.Lastupdate));
                        break;
                }
                return toReturn;
            }
        }

The problem is that if we use timestamp(3) we received and exception error when we try to save the entity, if we use timestamp without precision, we don't received any error and the entity is saved.

So i think the problem is here:

toReturn.Add(ComptadorFields.Lastupdate == compta.Fields.GetDbValue((int)ComptadorFieldIndex.Lastupdate));

the mysql sentence generated:

UPDATE `comptador` SET `numero`=69 WHERE ( ( `comptador`.`id` = 1) AND ( ( `comptador`.`lastupdate` = '20191217124239')))

As we can view, the precision of timestamp is not correct, and for this we received and exception error when we save the entity

Please any help of "guru"

Thanks

Fractional seconds as they're called in MySQL lingo aren't supported at the moment in our framework. You need the fractional seconds for the timestamp? According to this tutorial: http://www.mysqltutorial.org/mysql-timestamp.aspx you can do without, but not sure about your particular use case? (It's likely too imprecise as it's based on second precision)

In any case, our system ignores precision/scale etc. on datetime fields. Only MySQL has this feature, as for all other databases the actual datetime value is stored which is more precise than a string value as it's based on ticks, not seconds/milliseconds etc.

That said, using date/time based fields for concurrency isn't precise enough in most cases: you will run into situations where the value is equal while it's not to be equal: you need a value that's updated with every update, and which isn't depending on the time the update was performed. So I'd actually update a field of type char(36) or binary 32 with a guid every time you update the entity. That way you can reliably do concurrency control as you are guaranteed the value is changed when you save the entity.

You could do that in a trigger (MySQL 8 ) for instance.

At the moment that's what I can give you.

finally we solve it using fingerprint field with random value

Thanks @Otis