Ajax error 500 on save null value for float field

I have the same issue with a Term reference field. The terms are listed in checkboxes, when I uncheck all boxes and hit 'Save', I get the following error with an empty response (in dutch):

Er is een AJAX HTTP fout opgetreden.
HTTP-resultaatcode: 500
Debug informatie volgt.
Pad: /nl/system/ajax
Statustekst: Service unavailable (with message)
Antwoordtekst: 

The log report gives the following error:

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'tid' cannot be null: INSERT INTO {taxonomy_index} (nid, tid, sticky, created) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3); Array ( [:db_insert_placeholder_0] => 104 [:db_insert_placeholder_1] => [:db_insert_placeholder_2] => 0 [:db_insert_placeholder_3] => 1474364730 ) in taxonomy_build_node_index() (regel 1981 van modules/taxonomy/taxonomy.module).

Patch included

When an empty field is submitted, the field value in the $entity object is set to NULL, which results a db error
The patch loops the $entity object fields for NULL values and modifies the object so the $entity can be saved correctly.

patch in #3 works like a charm!

#3 seems to be working

Changed status to RTBC, can we get this into dev or stable release?

This may solve the problem but we shouldn't be hardcoding languages into the module this with 'UND'. Not sure the best way to handle this but maybe use entity_metadata_wrapper() and then you don't have to deal with the language.

Right, instead of the 'und' string the constant 'LANGUAGE_NONE' should be used. This has been updated.

Considering we are requiring Entity API, there is a helper to ensure that we are getting the right language. Typically it's on $entity->language otherwise default to LANGUAGE_NONE.

entity_metadata_field_get_language($entity_type, $entity, $field)

I'm a bit unsure the steps to reproduce this bug as you can create a schema that would allow NULL values and I've not seen this pattern to resolve this elsewhere in Drupal yet. So I'm setting this "Needs work" to provide steps to reproduce.

@Frederic wbase, please provide some sense that you tested this in your comment when switching the status to RTBC.

NULL values are not allowed by default if I'm not mistaken, what more information would you need to reproduce the steps? My issue appeared on the 'View' page of a node where I was saving a checkbox list that was completely unchecked.

I updated the patch where I ended up using the field_language function

Steps to reproduce:

1. Create a taxonomy list with a couple of terms
2. Add a new field with type 'Reference to term' and with the widget 'Check boxes/radio buttons', choose your newly created taxonomy list as reference
3. Add this new field to the display in your 'Display settings', choose 'Editable' in the field Format settings
4. Create a node, go to the frontend of that node, check a couple of random items of the checkbox field and save it
5. Uncheck ALL fields again and click save again, you should get an error

Thanks @cheval, the steps were helpful, except for "Select list" because you actually want "Check boxes/radio buttons" for the save button to show on the node display. May want to edit your comment above.

Here's a patch that fixes it and removes some of the kludge built up of the years. The validation is done through the _validate() step and calling it again messes with the values.

I tested it with views and without views and with and without validation and it works fine. Also tested the cache issues.

Give that patch a try.

@cheval when you have a chancel let me know if this will suffice because I'd really like to commit this.

Thanks for the update Joel, I'll test the patch as soon as I can.

Thanks for pointing out the error in my previous post, it's been edited :)

Your patch seems to be working, tested on a clean Drupal 7.54 installation.

I've tested both issues in this thread, saving an empty float field and saving a term reference checkbox list, both with success.

Thanks for testing it too, that cleans it up and leaves the validation in the separate validate callback function!

I've committed this to dev.