Problem/Motivation

Currently the energy value is stored in a field of the entity that is being measured (the subject). Updating the energy value invalidates the entity cache and the related render cache(es). For high trafic sites this affects behaviour and should be avoided.

Proposed resolution

Introduce a separate entity that stores the energy. An entity reference field is relates the subject entity with the storage entity. A special entity reference formatter with emitter is used. The formatter does _not_ pass the cache tags from the storage to the subject entity.

Remaining tasks

  • PoC
  • Performance test current and PoC situation.
  • Add tests
  • Add documentation

Issue fork radioactivity-2944943

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Sutharsan created an issue. See original summary.

ChrisSnyder’s picture

ChrisSnyder
he/him
CreditAttribution: ChrisSnyder as a volunteer and at Unleashed Technologies commented

I fully support this issue.

I am running into issues where we have way to many nodes and way to many revisions (created by radioactivity) that my DB queries are getting very slow.

Sutharsan’s picture

Sutharsan CreditAttribution: Sutharsan commented

@chrissnyder, I never not considered revisions. That shouldn't be hard to fix, will create a new issue for that.

Sutharsan’s picture

Sutharsan CreditAttribution: Sutharsan commented
Related issues: +#2953539: Don't create a new revision when updating the energy value.

#2953539: Don't create a new revision when updating the energy value.

Sutharsan’s picture

Sutharsan CreditAttribution: Sutharsan commented

@chrissnyder, can you explain in #2953539: Don't create a new revision when updating the energy value. about the revision that are created by radioactivity. I can not reproduce this.

ChrisSnyder’s picture

ChrisSnyder
he/him
CreditAttribution: ChrisSnyder as a volunteer and at Unleashed Technologies commented

@Sutharsan I can update that issue. Give me a some time to grab some proof from the sites I am experiencing the issue with and put together reproduction steps.

a.milkovsky’s picture

a.milkovsky
he/him
Location UTC +2
CreditAttribution: a.milkovsky commented

In Drupal 7 there was a possibility to update field value without triggering update hooks: https://drupal.stackexchange.com/a/99846/6309
Maybe we can find some way for d8 as well?

Heine’s picture

Heine CreditAttribution: Heine at LimoenGroen commented

The problem I experience with the current setup is the following scenario:

- an incident is created for node X.
- an editor loads node X to edit.
- cron runs and radioactivity incidents are processed, saving node X
- the editor is finally done and tries to save node X only to be greeted by the EntityChangedConstraint message

ChrisSnyder’s picture

ChrisSnyder
he/him
CreditAttribution: ChrisSnyder as a volunteer and at Unleashed Technologies commented

I have experienced the issue outlined in #8 as well.

Sutharsan’s picture

Sutharsan CreditAttribution: Sutharsan commented

I have a workaround for this problem:
- Create a paragraph type that contains a radioactivity field.
- Add a paragraph field to the node/entity that has one paragraph of the above type.
- Optionally override the paragraph-template to strip out the div wrappers and only display the content (= the RA field).

But this solution reveals another problem. The node/paragraph is saved with the energy value at the time of opening the node/entity form. Any change in energy value that happens in the meantime (processing emissions, processing decay) will be lost. I've created #3002698: Don't update the energy value when changed via the interface.

Sutharsan’s picture

Sutharsan CreditAttribution: Sutharsan at LimoenGroen commented
Status: Active » Needs review

I have a (partially) working solution with an entity reference field and a dedicated entity to store the energy. I can imagine that in the future this will replace the current solution, but at first they can exist side by side. Reviews are appreciated.

Sutharsan’s picture

Sutharsan CreditAttribution: Sutharsan at LimoenGroen commented

Known todo's
* BUG: Incident updates seem to override decay updates: Reproduce refresh a page with emitter; run cron; refresh the page; run cron. De decay value is not included (tabel radioactivity_field_data)
* Use RA entity in a View
* Force RAR field to be required (widget)
* Make RA-entity Translatable
* Add/check RadioactivityReferenceItem::generateSampleValue
* Readme documentation
* API documentation?
* Add tests

Sutharsan’s picture

Sutharsan CreditAttribution: Sutharsan at LimoenGroen commented

After many iterations I have an initial working version. Remaining bugs and task:

* When generating content (with devel generate) two RA entities get created, only one is used.
* In a View with reversed RA relationship, duplicate records are shown.
* Add tests

Because the patch introduces a BC breaking change in the processing of RA energy, I have decided to create a new branch. This which will include both the old and the new field type. But in due time I expect the current Radioactivity field type to be deprecated and to be replaced by the Radioactivity Reference field type.

Sutharsan opened merge request !1

Sutharsan’s picture

Sutharsan CreditAttribution: Sutharsan at LimoenGroen commented
Status: Needs review » Fixed

I've create a 4.0.x branch for this change as it introduces a BC breaking change in the Incident class.

Status: Fixed » Closed (fixed)

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

Sutharsan’s picture

Sutharsan CreditAttribution: Sutharsan at LimoenGroen commented

I proudly announce ...... that I have just created the 4.0.0-beta1 release with the Radioactivity Reference field. Thank for your input which eventually lead to this new development.