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
Comment From: rwinch
Thanks for the report. Can you provide a sample of that reproduces this issue?
Comment From: 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.
Comment From: 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.
Comment From: dadikovi
@igorpele do you still want to work on this issue? (I'm just asking because I'm looking for an issue to work, but I can find other one off course)
Comment From: igorpele
@dadikovi as I got no response on this issue, you are welcome to take it.