The Fields in Core working group aims to include CCK-like functionality in Drupal 7 and beyond. During the week of December 15, we're organizing a 5-day Fields in Drupal core code sprint at Acquia! To help us fund the sprint, please consider making a donation using the ChipIn widget on the announcement page. We need money for airline tickets, hotel rooms, food and transportation. It would also be great to fly in a few additional people with extensive core and CCK experience.
I've been experimenting with implementing complex fields by creating a field type that's also a fieldable entity.
But I've run into some problems in the form department. The issue is that $form['#fields'] makes it rather difficult to include a field in a complex element, when field implementations expect the form global #fields to include the the field and instance. It's 'just' form API #process functions that seems to be the problem.Read more
Extreame fields: Title and Body as fields for nodes; 'mail' (email) and 'name' (username) as fields for user
Has anyone talked about devolving title, body(for nodes) and mail and name for users into fields
One reason for this would be to have mail and name be non-unique if a setup called for that. See this comment.
If anyone has discussed this somewhere let me know?Read more
I've been thinking about the concerns about storing fields in separate tables and have another idea to knock around. Storing each simple field in its own table could obviously result in a lot of tables for each content type, but storing a few complex fields could significantly reduce the number of tables involved. So another option is to make it easier to create a complex fields to match the needs of a particular system. If that was easier to do, anyone concerned about performance could combine the fields they need into a smaller number (or even a single) complex field.Read more
Today I mostly goofed off at work and created the Per-Bundle Storage module (pbs.module), a Field API contrib module that stores all values for all limited-value fields in a bundle in a single table row. Per-bundle storage is the exact analog of pre-Field API CCK's per-content-type storage and thus provides the same benefits (namely, loading all such fields in a single query).Read more
We currently have three Field API groups: CRUD, Type, and Attach. As recently as Monday, chx was confused about what these names mean; he thought "Attach" was for attaching a field to a bundle. If he can be confused, then the names are just confusing. I propose that we change them as follows:Read more
We have a task for cleaning up the serialized data in the field_config_instance table. This includes preventing duplicate/inconsistent data from existing in the serialized data column and other columns, and considering whether some data now in the serialized column that did not used to be should in fact go back into its own column.
1. Preventing duplicate/inconsistent data
In _field_write_instance, we previously wrote $instance (the whole record) into the 'data' column. I changed the code like this:
// Create $data to contain everything from $instance that does not
Taken from email discussion - Quick summary :
is ugly, we should do :
module_invoke('field', 'attach_*', ...);
yched : This doesn't work because for this forbids reference-altering the arguments
chx: Then let's use the 1st form when by-ref args are needed and the 2nd one for the rest.
(end of summary)Read more
I think we need another Field Attach API function.
Currently, a fieldable entity calls field_attach_form($obj_type, $obj, $form, $form_state) to load the appropriate field elements into $form for editing $obj. Later, it calls field_attach_validate(..., $form, $form_state) so the field widgets can perform their validation. Eventually, it will call field_attach_insert($obj_type, $obj) or field_attach_update($obj_type, $obj) to store the field data in the database.Read more
We have a Field CRUD API task: "CRUD: API to load single field for single entity: Should take field, entity, and entity_id as arguments. Needed for Materialized Views."
I started to write this function, thinking it would be easy (ha). I decided to make it exactly like field_attach_load() except for a single object and with another argument for the single field to load, like this:
field_attach_load_single($obj_type, $object, $field = NULL, $age = FIELD_LOAD_CURRENT);
During the code sprint it was decided that core would not allow field attributes to be changed, only instance attributes. This was to prevent destructive changes, like trying to change a field type. But not allowing field changes creates another list of issues. Yves and I talked about this some last Friday (the last day of the sprint that got aborted by bad weather in Boston). Here are my (rough, unedited) notes from that discussion:
No field update:Read more
Several kinds of fields currently offer an 'allowed values' list where you can create either a hard-code list of possible value or some PHP code that will produce an allowed values list. The allowed values list is a field attribute that is shared between all instances of a field.Read more
Field API does not yet support revisions. It can easily enough, but we have a few decisions to make.
In D6 CCK, all per-field and per-content type storage tables contain columns for nid and vid but the primary key is vid. Multiple versions all go into the same table.Read more
We made a lot of progress during the Field API code sprint but the code is by no means "finished" for D7. Our planning spreadsheet shows many tasks remaining to be done, though not all of them are ever intended for core in the D7 timeframe. And, of course, we have yet to convince the community that our approach (particularly the per-field storage tables) is correct. So the code is in no way core-worthy yet.Read more
It's been a crazy and exciting week. We grappled with a lot of issues, went around in plenty of circles, and took some heat from the community. We did not accomplish nearly everything we wanted to but did achieve several important goals. The big one is that it is now pretty simple to "field-enable" any kind of object with minimal effort. We have field-enabled nodes and users.Read more
There have been quite a few posts to the Fields in Core group about the decision to put all fields in individual tables, despite the apparent scalability penalty of removing the per-content-type (per-"bundle" in the Drupal 7 Field API jargon) tables. The reason is that we have something better to replace it with, and we've decided to simplify the Field API code by removing now-unnecessary code related to per-content-type tables.Read more
Last updated by catch on Tue, 2008-12-16 14:56
We considered preserving support for table-per-content type. There are a lot of reasons why we wouldn't want to, and one of the primary objections to abandoning them is the performance penalty of increased JOINs. So, I decided to run some benchmarks.
I set up a benchmark environment:
* 64-bit RHEL 5
** Dual quad-core Xeon
** 8GB RAM
** RAID-1 10K RPM SAS
** PHP 5.2 with APC
** MySQL 5.0 (InnoDB)
** Apache 2.2
* Drupal 6.8
* CCK 6.x-2.1
* Devel 6.x-1.12
* Views 6.x-2.1
I set up a content type with the following fields (aside from included files):
* Text (single, unshared)
Last updated by David Strauss on Tue, 2009-01-20 20:17
Getting a working copy
- Download and install Bazaar. Packages are available for many platforms.
- Get a working copy: "bzr branch bzr://vcs.fourkitchens.com/drupal/7-fic my-fic-working-copy"
While you're working
- Run commits (bzr commit -m "My message") to checkpoint your work. These commits only affect your local working copy.