-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unchanged numeric value gets always updated #281
Comments
Your workaround is a good idea. A test could be to declare gosaMailQuota as binary attribute in LDAP connection. This should prevent LSC to force the value to be casted as String. |
Unfortunately, the behavior is still the same with attribute declared as binary: <ldapConnection>
<binaryAttributes>
<string>gosaMailQuota</string>
</binaryAttributes>
</ldapConnection> Should I try and change something on the |
Yes please try also to use this in your dataset: <dataset>
<name>quota</name>
<policy>FORCE</policy>
<forceValues>
<string>srcBean.getDatasetBinaryValuesById("gosaMailQuota")</string>
</forceValues>
</dataset> |
It's completely breaking data insertion as the dataset produces binary data that doesn't match database type:
|
My mistake, try getDatasetFirstBinaryValueById instead of getDatasetBinaryValuesById I don't have any idea after this... |
Insertion is working correctly, but records still get updated at each run. Thanks for the ideas :) |
I'm synchronising a LDAP to a MariaDB. The
gosaMailQuota
LDAP attribute goes toquota
in MariaDB, which is a bigInt:On the LSC side, the
quota
value is generated in a dataset:and extracted from SQL request in SqlMap:
In this first version, the value gets updated even if the LDAP value matches the DB.
I've tried converting the value to a numeric type, behavior is the same:
<string>parseInt(srcBean.getDatasetFirstValueById("gosaMailQuota"), 10)</string>
<string>new java.math.BigInteger(srcBean.getDatasetFirstValueById("gosaMailQuota"))</string>
To have LSC update the value only when it changes, I had to convert to string in SQL and compare with the value from LDAP:
and extracted from SQL request in SqlMap:
The text was updated successfully, but these errors were encountered: