Head2Head update for numeric list fields no longer being unsigned [#818530]

Core issue is here: #795198: Numeric List fields should not be unsigned

A bit tricky because we need to find only the appropriate field tables in the database and update them. I feel like there must be a simpler way to do this, but I couldn't find one.

I've tested the Head2Head function and it seems to work well.

Comment	File	Size	Author
	head2head-795198.patch	2.82 KB	David_Rothstein

Comments

Comment #1

yched commented 4 June 2010 at 19:02

Status:

Needs review

» Needs work

This code only works for fields using 'field_sql_storage' as their storage backend.
That is : $field['storage']['type'] == 'field_sql_storage'

For those fields, you'll find the storage info in $field['storage']['details']['sql'] :
- db table names, for both current revision and older revisions,
- and db column names, for all the field's 'columns',

dsm(field_info_field('body'));

(Those informations are present in the $field arrays returned by field_info_fields(), not by field_read_fields(), which only reads raw records from the field_config table)

For the fields stored in other, non-core storage backends, well - no real way to upgrade them...

Comment #2

David_Rothstein commented 4 June 2010 at 19:17

Status:

Needs work

» Needs review

Right, as the code comments say, this assumes field_sql_storage... I figure if anyone else who is actually using this module needs it to be more general, they can figure out how to rewrite it for that :)

field_info_fields() doesn't work for inactive fields - or am I mistaken? That's why I didn't use it and went with the more hackish method instead. On the other hand, I forgot about the fact that list.module is required by core. Does that mean there is no (realistic) way a list field can ever become inactive?? If so, then maybe field_info_fields() will work after all.

Comment #3

yched commented 4 June 2010 at 19:33

I was I bit fast on reading the patch, you're more aware of this than I assumed in my comment, sorry :-).

You're right that this code should also work when the fields are disabled (i.e field-type module is disabled). This currently cannot happen, but...
I don't think I remember exactly the chain of reasoning (if any) that led to number and list modules being required. There's currently no strong reason I can think of - which means this could go away any minute, and your approach is right.

Theoretically, though, there's no reason why could couldn't collect storage details for disabled fields. It might be worth delegating the code that populates those in _field_info_prepare_field() to a hepler function that could be reused for $field data taken out of field_read_fields().