Proposal for farmOS 3.x core datamodel improvements: Immutable Quantities & Soft Entity Deletion

I wanted to open this thread to test the waters for a couple of (I feel) key improvements to the core farmOS datamodel that should be considered for a version 3 (or 4?) of farmOS.


Immutable Quantities

Make quantities immutable and enforce that a single quantity is referenced by at most one log.

Rational: This makes changes to quantities more atomic and guarantees that the log’s changed timestamp is always updated when one or more of its quantities are changed.

Soft Entity Deletion

Make entity deletion an admin only action and provide a soft-delete (a.k.a. tombstone) mechanism for regular users (farm_manager, farm_worker). The logical choice here seems to be introducing deleted as a new status value - in addition to active and archived. (I’m open to other ideas - such as a dedicated boolean field too.)

Rational: This makes it easier for API clients to determine why an entity no longer “exists” - i.e. replication issue, database rollback, actual deletion, etc. It also makes data-loss easier to avoid in the case of a rogue user - i.e. rather than needing to get the data from a recent backup, it just becomes a matter of rolling the entity/entities back to an earlier - not “deleted” - revision.

Next Steps:

On a recent call I remember we talked about maybe having a more formal proposal mechanism - like PEP. “farmOS Enhancement Proposals” (FEP) anyone :nerd_face:?

I’d be happy to pilot such a mechanism if there’s interest… regardless of that I’d welcome any/all feedback on the above proposals.


Love both of these proposals @Symbioquine! Thanks for getting the conversation started. :slight_smile:

Yes!! :smile:

At the risk of bikeshedding… “FIP” is another option (“improvement” vs “enhancement”, eg: BIPs). Either way! I love the idea of formalizing this process for core data model changes moving forward.

This might allow us to remove our dependency on Entity Reference Revisions, and the extra complexity (eg: Issue #3267304) that it adds for API requests.

Feels like there will be a lot of code considerations with this change… curious to start thinking it all through…

This has been something I’ve wanted to see for a long time. :+1:

It will also require a fair bit of thought and extra logic to hide “deleted” status entities throughout the UI (and API?)


Thanks for the enthusiasm!


Yeah, I’m thinking it might not be too bad if we use the permission system…

Okay, I’ll bite…

  • GIIFT: Great Idea to Improve farmOS Today
  • FIELD: farmOS Immediate Enhancement Lightweight (Design|Draft)
  • FEAR: farmOS Enhancement Action Recommendation
  • FBI: farmOS Betterment Idea
1 Like

I think we’ll need to start a commission to decide what makes the most sense. /s :rofl:


Curious to understand how this helps with complexity… removing ERR would be nice, but do we create something more complex in its place? Right now to modify a quantity you must update the log.quantity revision_id after modifying the quantity entity. With this proposal you would need to create a new quantity as a “copy” of the “old” quantity with intended changes, remove the old quantity from the log.quantity field, and add the new quantity to log.quantity. Does that sound right?

1 Like

I was only referring to the extra “API surface complexity” that the ERR module adds by requiring the revision ID be specified in addition to the entity ID. That is an outlier in terms of the rest of our data model. Only requiring the entity ID would bring it in line with everything else, but there’s a lot more complexity added in other code to enforce immutability I agree. Whether or not that’s justified is up for discussion.

Quick note for future reference/detail: @paul121 and I were discussing in chat about some boilerplate PHP methods on the Asset/Log/(others?) entity type classes like getName() and getOwner() that might be worth deprecating in 2.x and removing in 3.x. They were created initially because it’s standard practice in custom Drupal entity types, but they aren’t really necessary and aren’t really justified - we could reduce the API surface a bit by removing them. Plus the getOwner() field is misleading… it returns the uid of the entity, not the owner field values that we add via the farm_owner module.


That’s definitely what I was suggesting - though typically some convenience mechanism would be provided in the write parts of the API to simplify doing so.

Thanks for pointing this out @paul121! I’ll need to play with it a bit more, but I think this actually may address most of my motivation for that part of this proposal.


  • That this guarantees that all well-formed quantity views/calculations will never see a partially modified set of quantities
  • That this guarantees that the log changed timestamp will always be updated when any quantity associated with the log is changed

Given the above, I think the only bit of this proposal regarding quantities left would be to enforce that a single quantity entity can’t be re-used for multiple logs.

Yeah, I’m not stuck on it. There’s a lot to be said for leveraging existing platform patterns, even if we might build it differently ourselves otherwise.


Is farmOS currently making use of the Published boolean for Quantities?

1 Like

No, quantities are their own entity type, and they don’t have a concept of “published”. farmOS doesn’t use Drupal node or comment entities for anything currently.

The available quantity attributes and relationships are described here: Quantities | farmOS

I suggest that if something is not removed from the database, it should not be called “deleted” - brainstorming around alternatives:


FYI I started a meta issue to track all the breaking changes we might want to propose/consider for farmOS 3.x: [META] farmOS 3.x Breaking Changes [#3347412] |