I want to create a DR8 content field, which has no field tables, and passes the save and load mechanisms to a custom table. Is there a way to do this? I've been able to prevent saving with:

class MyCustomFieldType extends FieldItemBase {
public function __construct(DataDefinitionInterface $definition, $name = NULL, TypedDataInterface $parent = NULL) {
$def = $definition->getFieldDefinition();
$storage = $def->get('fieldStorage');
$storage->custom_storage = TRUE;
$storage->set('fieldStorage', $storage);
$storage->set('cardinality', -1);
parent::__construct($definition, $name, $parent);

Yet this does not prevent the creation of the tables. After that, I'm not sure how to implement the custom save functions. Now I realize, I could do all of this with hooks, even the field widget, but I want to latch into the real drupal mechanisms to do this more cleanly. And I do want the content entities to which the field is connected to perform a task based on the save and load events.

Do I have to force all entities using this field to use a custom storage class, and is this possible, or is there a more minimal intervention? Are there any experts out there, who have done this, who can help?

  • Personally I've never done this, but because I haven't seen a reason to. Why are you wanting to change the tables to custom storage? – Jaypan Mar 26 '19 at 10:57
  • Because my tables are entities, which need to be related to two different entity types, and using entiity references would add yet another set of tables, and also make checking consistency very complicate. I really just need to do something special on save events. I did something like this with hooks once, but putting widgets into the Entiy Form configuration form is a real mess (see field_groups module). I would be much cleaner, if I could create a dummy field with widgets and let drupal handle the rest. – jmux Mar 26 '19 at 11:07
  • In a any case, $storage->custom_storage = TRUE; must be there for something, no? – jmux Mar 26 '19 at 11:08
  • If you're trying to store multiple field values (cardinality -1), you're going to need multiple data tables anyway aren't you? Unless you commit a relational DB sin and try to stash multiple values in a single column. I doubt this is worth the hassle, and any performance gain would be vanishingly small unless you're dealing with billions of records on questionable hardware – Clive Mar 26 '19 at 11:55
  • That's not really my issue. And the (cardinality -1) is taken care of by my entity, which is simply a content entity with its own table. It basically acts as the conector table in a symmetrical n:m or n_n relation. It's about producing a form widget, that access the table from two different entity types, and still can be managed the same way regular form widgets are managed in the backend. – jmux Mar 26 '19 at 12:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.