Switch to serial primary keys

This patch implements the straightforward conversion of field_config and field_config_instance to use serial primary keys. field_read_instances uses the field_id instead of field_name to join. The entire API still works in terms of field_name.

This will help/make possible batch delete and a host of other things.

I fixed the double spacing; sorry, in grade school I was taught that two spaces are correct and one space is wrong. :-) I changed the PHPdoc to say the ids are "managed automatically" (they are not always generated, sometimes they are copied).

The id and field_id fields are not just internal, just like $node->nid is not internal. They are the primary identifiers and foreign keys for these objects. Other modules are free/encouraged to use them for joins etc.

Since yched's comments were all doc-related and I addressed them, RTBC.

@dries: Fair point. First, review the intro paragraph of the Field API data structures doc:

 * The Field API defines two primary data structures, Field and
 * Instance, and the concept of a Bundle. A Field defines a
 * particular type of data that can be attached to objects. A Field
 * Instance is a Field attached to a single Bundle. A Bundle is a set
 * of fields that are treated as a group by the Field Attach API.

Now, I've changed the PHPdoc for the Field Instance structure (mainly by adding the phase "foreign key"). Does this clear it up?

 * @param array $instance:
 * - id (integer)
 *     The primary identifier of this field instance.
 * - field_id (integer)
 *     The foreign key of the field attached to the bundle by this instance.
 * - field_name (string)
 *     The name of the field attached to the bundle by this instance.
 * - bundle (string)
 *     The name of the bundle that the field is attached to.

@yched: I like your changes, but made two more:

1. You missed a use of the "managed automatically," I updated it.

2. It isn't just id and field_id that are assigned automatically, it is all read-only properties. If a property *isn't* assigned automatically, it isn't read only, and shouldn't be marked as such. So I changed everywhere that said "id is assigned automatically" to "read-only properties are assigned automatically."

Now, I am sorta wondering whether we should even that say that at all, because the whole point of documenting that it is read-only is to concisely identify that it is READ ONLY and cannot be set, changed, etc. from outisde the API. If all Drupal APIs documented their data structures as Field API does (oh, happy day!), would we really want all of them to say "read-only properties are assigned automatically"? It seems redundant.

Anyway, we're just tweaking the documentation. The most recent version of the patch can be committed at any time. :-)

I disagree that the ids are for internal purposes only and should be moved down the list. It is true that our API treats fields as identified by name, not by id, but that is a holdover from not having ids and I suspect it will eventually change. Any module that wants to use the Field CRUD hooks to do extra stuff will want to use field id instead of name as the foreign key, at which point there will be strong incentive to change the API to use ids for real. Also, I suspect implementing the batch delete and/or the ability to create, delete, and re-create a field named 'foo' will require changing our concept of "field names are unique" in one way or another; the field ids will be unique instead.

So, I think the PHPdoc re: id and field_id is fine for now. If/when we change the API as discussed above, that will be a separate issue. Therefore, I suggest that this issue really is fixed.

yched, if you agree, please set to RTBC so hopefully Dries will mark it fixed. :-)

Heh, that's funny. There is no new patch, so the testbot is trying to re-apply the patch from #8 that has already been applied and thus fails. Let's see if an empty patch file works around the proboem.

Please review the comment in #12.

Looks fine to me.