Object ID Identity conversion to long fails on old schema

[nucatus]

Summary

In case of an old ACL schema where the object_id_identity is of type bigint instead of the current varchar(36), the conversion of the identity to a known type fails.

Actual Behavior

Conversion of ACL object ID identity fails.

Expected Behavior

Conversion of the ACL object ID identity should succeed to a known type, or long if no class_id_type is provided.

Configuration

Version

5.2.x

[rwinch]

Thanks for the report. Can you provide a sample of that reproduces this issue?

[nucatus]

Well, I was just looking at the history of the aclSchema and noticed that the type of the object_id_identity field changed from BIGINT NOT NULL to VARCHAR(36) NOT NULL when support for non-Long IDs was added.

In our project we have a schema where the type is BIGINT UNSIGNED NOT NULL. When data is extracted from the ResultSet, the mysql driver will convert this type to a BigInteger. In the previous version, this was not an issue, because the conversion to Long was carried on the else branch of the hasConversionService(). This changed with this update, where this check is buggy, because canConvertFromStringTo(Long.class) will always return true, no matter the source type, and it's passing the call to the convertService.

Indeed, this works with the original schema, but in our case, where our schema is slightly different and the type that the mysql driver returns is a BigInteger, it fails because it is looking to convert it with the conversionService, instead of falling on the else branch where the conversation works for other, unknown, types.

[igorpele]

Hi, I would like to work on this. As far as I understand, it only has to be verified that the conversion from String to Long is executed only if the identifier is an instance of String.