As some selection views are quite expensive in terrms of execution time, it seems a natural solution to cache (e.g. by time).
This has caused issues here. How to reproduce:
* Create an entityreference field with a selection view on a node
* Set a (say) 1-hour time cache on the view
* Edit one node and submit => no problem
* Edit another node with another entityreference target value and submit => Validation error: "The referenced entity (...) is invalid."

Debugging this in entityreference_field_validate() shows that $valid_ids has the target value of the first edit.

Comments

Anonymous’s picture

I have encountered exactly the same problem. With caching, 'The referenced entity (...) is invalid', without caching, no problem.

selwynpolit’s picture

Issue summary: View changes

ditto. I guess other folks haven't found this to be a big issue so I'm turning off caching on those views for now.

bjcooper’s picture

Just chiming in to say that I've run into this exact same issue. In my case, caching the View would provide a significant performance increase, so having to turn off caching for the Entity Reference views is slightly more than irritating.

I haven't looked more into it, but here's the description of my situation and my impression of what's going on:

My Setup

  1. I have a vocabulary of "Rooms" terms.
  2. User profiles have an "Office" Entity Reference field, which indicates which "Rooms" term is their office.
  3. I use a View to generate the "Office" field entity options. The View is an Entity Reference display that returns a subset of the terms in my "Rooms" vocabulary that are offices.
  4. The View uses a time-based caching to cache the results for one hour.

How to Make Bad Stuff Happen

  1. Edit a user and set their "Office" field. The changes will be saved successfully.
  2. In the same hour, edit another user and set their "Office" field. Form validation will fail with the error message this thread is about.

Why I Think Bad Stuff Happens

  1. The Entity Reference view generates the "Office" field entity options on the first user edit.
  2. For some reason, whatever you select as the field value gets caches as the View result.
  3. When you edit the second user, the entity reference validation gets a list of valid entities from Entity Reference view.
  4. It returns the cached result--which is the entity selected on the first user edit.
  5. Unless the second user has the same office, the newly selected "Rooms" term id will not match the cached View result, so it appears invalid.
geek-merlin’s picture

I did not investigate this further, but i remember there are some views issues about "caching does not respect arguments" or so.
Guess this might do the trick.

MustangGB’s picture

Priority: Major » Normal
Status: Active » Postponed (maintainer needs more info)

Is still still something that needs fixing?

spelcheck’s picture

@MustangGB, yes please keep this open. Though it's possible this will end up being issue with entityreference_filter.

I'm also using entityreference_filter with entityreference. I've only started to diagnose the issue, but so far when using a entityreference_filter view for my entityreference fields, I'm seeing the same issue as in #3. If the filtering view has *any* caching, entityreference_field_validate() $valid_ids appears to populate with $ids from the entityreference field that was processed immediately before it. It is looking to be intermittent, so I'll put time into properly diagnosing it.

Meantime #2 is a workaround, albeit a performance hit.