A lot of times we come across a requirement where we need to manage some additional data for the Drupal entities. Now, if we think simply, the solution is to create fields .. right... easy and best, that's what Drupal is all about, entities and their properties as fields. But, there can be scenarios where the entity is not fieldable (as of now).
We will be specifically focusing on them in this post, though this can be implemented for any entity, the key is to understand what we want to solve and how, it's a kind of trade-off that we need to do while making any decision. As I always say Drupal has a lot of ways to solve a problem statement, it's you who decide which is the efficient one. You may not find the below solution as most efficient or scalable for you, but definitely, you would draw some important knowledge/information from this post.
So, let's consider a scenario where you want to store some additional information for Menu Item Entity, now by design in Drupal core, this entity is not fieldable as of now. So, the best approach is to look for contrib modules, and yes there is a module: Menu Item Extras and this will allow you to create fields and manage the additional data.
Then what's the problem in this?
Definitely there is not problem, but sometimes you just want to store relevantly small data and if you know Drupal closely, any new field, would create a separate table in the database, question is does that affect you? If no, please go ahead and create field to solve your problem statement, but you may want to think that if there would have been an additional column in the corresponding menu table (menu_link_content_data), that itself would have been sufficient. So, why not let's just do that?
But before doing this, you need to think of scalability of the solution, additional separate table (via field approach) would have given you better grip in terms of search and sort functionality, around the data you are planning to store in the field. But if that does not matter a lot, and can be managed by storing the data just in an additional column then probably you should go with this approach, it's always better to have less code, less modules, less tables and hence better performance (depends on lot of other factors also ;) ).
Now, question is: How to add an additional column to that table?
Hook_update - Nopes, not anymore, in Drupal 7, db_add_field was being used for this, but now the best way is to use hook_entity_base_field_info to inform Drupal about the new base field (column will be created correspondingly). Check different base field types that can be created here, you have primitive types and for complex you can always use map, use setComputed function carefully to allow/disallow Drupal to exclusively control storage and retrieval of the data from the FieldStorage. It's advisable to allow Drupal to control these things via setting setComputed as FALSE or not setting it to TRUE. Then for the form, you just can add simple form alter to add the form element for this additonal data and Drupal will take care of saving the data to the entity.
Now, the key over here is to before implementing any final solution, if possible given the time, try to deep dive into the entity you want to customize to understand it better and then based on that decide what should be the best solution. Remember it should be maintainable as well, I don't want to complicate this... Life should be simple no...??
Comments