Single term field and index hierarchy data alteration conflict

I've just managed to get indexing of parents working for that fields by manually altering the primary key of the tables just after configuring the data alteration.
---
alter table search_api_db_nodes_field_myterm drop primary key;
alter table search_api_db_nodes_field_myterm add primary key (item_id, value);
---

I saw that submitting the data alteration form rebuilds my field tables, so I guess the search_api_db module have some way to know that it will receive multiple values and simply isn't "checking" it.

I guess this has something to do with service.inc:createFieldTable method where it currently does
"if ($type != $field['type']) {" to decide if the field is a list or not.

Maybe it should do "if (search_api_is_list_type($field['type'])) {" but I think this is not the issue, as if search_api_is_list_type just checks for "list<" so the current check should work too.

Maybe this is a bug in search_api SearchApiAlterAddHierarchy class and its propertyInfo method that should change the field type to list if the hierarchy indexing is enabled? (it seems the code try to do this, not sure it succeed or it contains bugs).

Unfortunately I'm a newbie to search_api/search_api_db/facet_api so I need some help/pointer before I can try to produce a patch.

I've investigated this a while but I'm totally lost. It seems that the tables are regenerated when search_api_admin_index_workflow_submit is called but I debugged the service.inc:fieldsUpdated (search_api_db) called during that submit and "$fields" and "$new_fields" contains inverted options. So it seems that $fields contains the list type while $new_fields contains type integer type for my term with hierarchical option enabled.
So, it seems it updates the DB using "outdated" (or inverted) data.
$this->index is not corrent in that instant. When the form has been submitted and redisplayed the debug for $this->index instead gives the new updated values (but the search_api_db fields have already been created with bad values).

Here is my attempt to fix the issue. Unfortunately I don't feel confident this is the right solution, but at least this fixes my own indexing issues, so maybe it will be good to test for anyone else with the same issues.

I have to add that I am on latest dev snapshot for entity and search_api (2012/03/21).

The weird thing is that I get the "old fields" record for the getFields() but then I read the "old type" from the index->original->options structure because the one in getFields() is already updated in that place. Still I need to loop through the getFields() result because it is the only place where I can read the "table" names.

It never happened since that patch. Thank you.