>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3381298. --> Reported by: [dcam](https://www.drupal.org/user/1791830) >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>The Feed entity hash is a record of the feed's state when it was last downloaded. It allows us to skip processing the feed if its contents have not changed since the previous download. Currently it is stored as a property of the Feed entities. I believe that if this module were designed in the D8 era, then the hash would be stored in the State API. I don't think it makes sense to store this in the entity anymore. It could potentially cause problems. For instance, if anyone happens to be synchronizing Feed entities between sites, then the receiving site would get that hash and potentially think that it shouldn't update its items. Let's have this value indicate the state of the site, not the state of the entity.</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>We would remove the hash from the Feed entity baseFieldDefinitions(). The only question that I have is: should we deprecate and later remove the hash getter and setter? Or should we repurpose them to communicate with the State API and just keep them forever? I don't know that there's any reason we shouldn't do that other than adding a responsibility to the Feed class. And it could be a good idea so that calling code doesn't have to figure out how to construct the state key.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ul> <li>Reach a consensus on what all should be done.</li> <li>Write a patch.</li> <li>Commit</li> </ul> <h3 id="summary-ui-changes">User interface changes</h3> <p>None</p> <h3 id="summary-api-changes">API changes</h3> <p>TBD</p> <h3 id="summary-data-model-changes">Data model changes</h3> <p>Delete the Feed entity's hash property in baseFieldDefinitions().</p>