Catch binary puid misconfiguration if incorrectly set by user

Hi

Glad you got it working again.

I've reopened the issue per your comment that we should ideally catch this. I'm hesitant to just check for the non printable characters or null bytes or try encoding detections, since that could introduce subtle parsing bugs. However, if someone knows of a robust solution for this, I'd be open to it. Thus I've set it to postponed for now.

The only other thing I can think of would be to present a warning for the most common known binary ID attributes.

Hi all,

I just ran into the same error, but in my case the binary option is set:

The error message is:

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[22007]: Invalid datetime format: 1366 Incorrect string value: '\xD07\\xD91\xF8...' for column 'ldap_user_puid' at row 1: INSERT INTO {users_field_data} (uid, langcode, preferred_langcode, preferred_admin_langcode, name, pass, mail, timezone, status, created, changed, access, login, init, default_langcode, ldap_user_puid_sid, ldap_user_puid, ldap_user_puid_property, ldap_user_current_dn, ldap_user_last_checked, ldap_user_ldap_exclude) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14, :db_insert_placeholder_15, :db_insert_placeholder_16, :db_insert_placeholder_17, :db_insert_placeholder_18, :db_insert_placeholder_19, :db_insert_placeholder_20); Array ( [:db_insert_placeholder_0] => 49 [:db_insert_placeholder_1] => de [:db_insert_placeholder_2] => de [:db_insert_placeholder_3] => [:db_insert_placeholder_4] => xxx [:db_insert_placeholder_5] => xxx [:db_insert_placeholder_6] => xxx [:db_insert_placeholder_7] => Europe/Berlin [:db_insert_placeholder_8] => 1 [:db_insert_placeholder_9] => 1610708037 [:db_insert_placeholder_10] => 1610708037 [:db_insert_placeholder_11] => 0 [:db_insert_placeholder_12] => 0 [:db_insert_placeholder_13] => xxx [:db_insert_placeholder_14] => 1 [:db_insert_placeholder_15] => xxx [:db_insert_placeholder_16] => *�7\�1�B�;+l [:db_insert_placeholder_17] => objectsid [:db_insert_placeholder_18] => xxx [:db_insert_placeholder_19] => 1610708038 [:db_insert_placeholder_20] => ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->saveToSharedTables() (Zeile 1047 in /core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

I'm posting into this issue to find out if @bahuma20 was able to solve the error by checking the checkbox in 8.x-4.x as it was also his initial problem.

Regarding the warning I agree it would make sense to catch this and throw a detailed error.
I think this discussion is helpful, especially the reference to the Symfony implementation, which I guess is a good reference!
https://stackoverflow.com/questions/25343508/detect-if-string-is-binary

Great ... it seems I did the same thing wrong as @bahuma20. As you can see from the screenshot above I thought the option in the SERVER SETTINGS was the relevant one here, but that's wrong. Like @bahuma20 I didn't see the other option in the Drupal Mapping list:

So now there are two blind people... and based on my wrong assumption I'd suggest the following:
- Check values for binaries like written above to prevent such errors, see #6 for ways
- Auto-check binary checkbox in code in the Drupal Mapping overview if the field is set to be binary in the server settings - I think this will prevent many users from our mistake

Since this behavior is different than the drupal 7 version of the module and is not an intuitive change, it would be a good idea to add a HIGHLIGHTED note in the server setup indicating what needs to be done in the Drupal Mappings.