I need to clear my understanding of the Field SQL storage module. Hope someone here can answer my questions.
Currently Field SQL storage won't update fields if they're already have any data and/or if information about db columns has been changed.
But if I need a field with flexible schema information, which can change with time (i.e. db columns can be added or removed from field schema) with Field SQL storage I can't achieve that. Am I right?

So, if I'm right I have two questions:
1. Is this "by design" or this "feature" can be added in core (by "feature" I mean adding/removing db columns for existing fields with data)?
2. If this is "by design" can someone explain the reasons of that behaviour? Is it resource intensive task (but I think it's not) or something?

I think adding or removing database columns is not that hard or difficult (we are already doing this often in hook_update_XXXX() for our modules).
Anyway, I know I can write my own storage engine which will do that, but I really think that this functionality must be in core.

Thanks in advance,
Anatoly.

Comments

damien tournoud’s picture

damien tournoud commented

Short answer: This is by design.

Long answer: Fields themselves are supposed to have a fixed schema. It wasn't in the design decisions of the field API to support flexible-schema fields. Even more then that, changing the type of a field with existing data is not supported by the API. It is a complex task that can (and will) be supported in contrib.

yched’s picture

yched commented

This is by design, and the reason for this is that there is no way we can ensure data integrity on large datasets. CCK D6 received occasional reports of data corruption after db schema reconfiguration.

As you point, those kind of schema change operations is common in hook_update_N(), and those face the same possibility of breaking a database. hook_update_N(), however, are executed in a "maintainance" context with explicit recommendations to backup the db beforehands, and where users are more aware that something might go wrong. Having your db break after an innocent change in the regular drupal admin interface is different.

What you can do as a workaround, is try to have your schema account for the various cases in advance. E.g, core text fields always come with a 'format' column, which is actually used or not depending on whether the field is later configured to store plain text or formatted text.

LaurentAjdnik’s picture

LaurentAjdnik commented

Subscribing

an.droid’s picture

an.droid commented

Thanks for the detailed answers. The logic is clear for me now.
I'll try to find the way to solve my tasks with core Field SQL storage module.
But if there is no way, then I'll try to write new storage engine. However, as I can see now, that storage engine must take care of data integrity and updates of fields schema must not be done "on the fly".

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Status: Active » Closed (works as designed)