Alterations of EFQ needs to be made more robust [#1491454]

#1325628: EntityFieldQuery::propertyQuery missing fully qualified column names causes ambiguous column DB error uncovered a couple of issues in our manual alterations of the SelectQuery generated by EFQ:

$condition is not necessarily an array (it can be a string), and its 'field' key is not necessarily a string either (it can be a DatabaseCondition)
We hardcode the name of a couple of fields and follow the current broken logic of having entity-level properties not being fully qualified

Comment	File	Size	Author
#1	1491454-entityreference-alterations-efq-robust.patch	2.77 KB	Damien Tournoud
#1

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

Damien Tournoud CreditAttribution: Damien Tournoud commented 20 March 2012 at 20:11

Status:

Active

» Needs review

File	Size
1491454-entityreference-alterations-efq-robust.patch	2.77 KB

Here is a patch. It passes the unit tests.

Comment #2

Damien Tournoud CreditAttribution: Damien Tournoud commented 20 March 2012 at 20:19

Status:

Needs review

» Fixed

Merged into 7.x-1.x.

Comment #3

3 April 2012 at 20:20

Status:

Fixed

» Closed (fixed)

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

Comment #4

damien_vancouver CreditAttribution: damien_vancouver commented 6 April 2012 at 18:49

Hopefully this is an appropriate place for this… if not please point me at the right place.

Thank you for that clarification on #1325628: EntityFieldQuery::propertyQuery missing fully qualified column names causes ambiguous column DB error on the broken field configuration - that was why my test site was still failing. But, I wasn't using features - I created the field using the GUI with entityreference 7.x-1.0-beta3 (trying to reproduce the problems by @wipeout_dude on #1325628). I now see that the problem with my field config was likely fixed by #1276272: Don't display bundle selection if the entity type doesn't have a bundle key, at least in terms of saving new fields.

I'm concerned that anybody who created an entityreference userreference field before 7.x-1.0-beta4 is going to have the invalid field configuration in their database. Which after 1325628-23 gets committed to D7, might start affecting a lot more people.

Since the fix appears to be just re-saving the field with default settings and letting the new entityreference properly save the field config (without target_id I presume), then is the field configuration problem something that could be detected and fixed automatically for people with an update hook?

I can do some testing with 7.x-1.0-beta3 and creating fields and verify all of the above if it would be helpful. If an update fix is impractical, then maybe we just need a well documented issue for people to find when they search. The error condition would be getting no results back from Autocomplete, rather than the AJAX error seen previously. I can work out exact details for an issue if that's the correct way to go...