Contrib.social

[META] Plan entity relationships with metadata

Open on Drupal.org →
Created on 11 December 2020, over 4 years ago
Updated 17 February 2024, about 1 year ago

Problem/Motivation

farmOS provides a "Plan" entity type, which is used as a way of organizing Asset and Log entities around a particular purpose. For example, imagine a "Crop Plan" (bundle) which provides features for organizing "Plant" assets and "Seeding", "Transplanting", and "Harvest" logs with the purpose of planning and executing a crop plan for the season.

In farmOS 1.x, we did not use Entity Reference fields for these relationships, because we needed to store additional metadata alongside each relationship. For example, in a "Crop plan", we want to link "Plant" assets to the plan, but we also want to store things like "Days to transplant", "Days to harvest", "Harvest window", etc alongside each relationship, so that we can render a timeline view of multiple plant assets within each plan (imagine a "2020 Lettuce crop plan" with 20 varieties of lettuce, with successions, etc. So a simple Entity Reference field is not enough.

One option is to create a custom field type that extends the Entity Reference field type and adds additional columns to the database table. This was more difficult in Drupal 7, so instead we just created our own database tables with hook_schema() to represent these relationships, and bypassed the use of fields entirely.

For context, here is the 7.x-1.x Crop plan module: https://github.com/mstenta/farm_crop_plan/tree/7.x-1.x

And specifically the table we created to represent those relationships: https://github.com/mstenta/farm_crop_plan/blob/7.x-1.x/farm_crop_plan.in...

Proposed resolution

In Drupal 9 / farmOS 2.x, I would like to reassess the possibility of extending Entity Reference fields for this purpose. Field types are classes in D9, which makes this a lot more feasible.

The benefit of using Entity Reference fields is we can leverage the Entity Reference Integrity → module to prevent deletion of assets and logs that are associated with a plan. In farmOS 1.x we have a bunch of custom constraint logic to achieve this, which I would love to leave behind. However, we will have to investigate whether or not Entity Reference Integrity supports field types that extend from Entity Reference fields, or if a patch might be necessary to support that.

I asked about these ideas in Drupal Slack, and @kim.kennof pointed to this module: https://www.drupal.org/project/entity_reference_override → - which appears to be a good example of what we are trying to achieve.

It is also worth noting that this level of complexity may not be necessary for all plan types. Some may work fine with a standard Entity Reference field. So it may be worth considering adding a simple Asset and Log reference field to all Plan bundles by default (using BundleFieldDefinitions per #3183372: Convert config fields to base/bundle fields → ), but allow them to be disabled on a per-bundle basis when a plan type provides their own more advanced reference field.

I'm also curious if we can create a standard base class to use for these kinds of things - to make it easier for contrib to provide their own plan types with these advanced reference fields.

Remaining tasks

-
- Review Entity Reference Override → module to understand how it achieves the same goals, and what considerations it has dealt with.
- Investigate whether or not Entity Reference Integrity → supports custom field types that extend from the core Entity Reference field type.
- Experiment with providing a custom field type in the farm_crop_plan module's 2.x branch.
- Provide base class(es) to make it easier for other contrib modules to do similar things.
- Document how to build custom plan relationship fields for contrib plan types.

User interface changes

None.

API changes

Another benefit of this approach is that we would get JSON:API exposure of the plan relationships for free, which is not something we have in 1.x currently. So this would allow for Plans to be utilized via the API in even more ways.

Data model changes

Instead of bespoke database tables for representing Plan entity relationships, we would be using Drupal fields, and all the nice things that come with that.

🌱 Plan
Status

Fixed

Version

3.0

Component

Miscellaneous

Created by

🇺🇸United States m.stenta

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment almost 2 years ago →
    🇺🇸United States m.stenta

    Talked with @paul121 about this today, and we're starting to refine some decisions... nothing in stone yet but wanted to capture it here:

    "What should the entity type be called"?

    We're leaning towards plan_record for entity type name. It is short and sweet, and implies a relationship between a "plan" and a "record". And then bundles could be created of that for specific plan<->record relationship types.

    "Should the plan reference the plan_record entities via an entity reference field on the plan? Or should the plan_record reference the plan in an entity reference field on itself?"

    The nice thing about the reference being stored on the plan is it can be done by a specific field, which can give the connection more meaning. For example, maybe a plan references two kinds of assets, and wants those references to be maintained in two separate fields.

    This also relates to the next question...

    "Should it have any base fields? Or just bundle fields?"

    Still TBD. Might be good to include some basic hidden metadata base fields like created, changed, uid, etc.

    "Should they be revisionable?"

    This is a similar decision we went through for quantity entitites. It means that we need to use an entity_reference_revisions field instead of an entity_reference field.

  • Comment over 1 year ago →
    🇺🇸United States m.stenta
  • Comment about 1 year ago →
    🇺🇸United States m.stenta

    Update: I opened a pull request with a proposed approach to this...

    https://github.com/farmOS/farmOS/pull/781

    "Should the plan reference the plan_record entities via an entity reference field on the plan? Or should the plan_record reference the plan in an entity reference field on itself?"

    Worth noting... I went with a plan reference field on the plan_record entity type instead of a reference field on plan entity, for reasons described in the PR.

    The nice thing about the reference being stored on the plan is it can be done by a specific field, which can give the connection more meaning. For example, maybe a plan references two kinds of assets, and wants those references to be maintained in two separate fields.

    After giving it more thought, the same "meaning" can be achieved with multiple plan_record types, and the complexity of managing field references on the plan itself seemed unnecessarily burdensome.

  • Status changed to Fixed about 1 year ago
  • Comment about 1 year ago →
    🇺🇸United States m.stenta
  • Comment about 1 year ago →
    System Message

    Automatically closed - issue fixed for 2 weeks with no activity.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024