Closed (outdated)
Project:
Drupal core
Version:
7.x-dev
Component:
entity system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
7 Feb 2011 at 21:39 UTC
Updated:
14 Oct 2015 at 17:44 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
bojanz commentedLet me take a look.
Comment #2
bfroehle commentedWell, the problem is the selectQuery
gets turned into countQuery incorrectly:
Comment #3
damien tournoud commentedNo, the problem is that the user entity has no bundle.
Comment #4
damien tournoud commentedComment #5
bfroehle commentedInspired by #423888-16: Use subqueries for ->countQuery(), at least for MySQL, here is a band-aid which demonstrates that the sample code in the original post isn't crazy.
The real issue here is SelectQuery::countQuery() inappropriately removes variables defined in expressions which also appear in WHERE or HAVING clauses.
Comment #6
chx commentedComment #7
chx commentedComment #8
sunWouldn't a simple clone be faster/more appropriate?
Powered by Dreditor.
Comment #9
bfroehle commentedI have no idea, but the patch is attached.
The whole thing is just a giant band-aid to a larger problem, alluded to in comment #5.
Comment #11
dave reidHoly crap this issue got derailed. The original problem here is that the SQL should not result in a bundle condition if $entity_info[$entity_type]['entity keys']['bundle'] does not exist. That's *IT*.
chx is filing the DBTNG issue.
Comment #12
dave reidHere's a patch that at least fixes the bug by using the same logic as the revision key
Comment #13
chx commented#1258000: SelectQuery::countQuery() inappropriately removes SQL expressions is the other issue.
Comment #14
bfroehle commentedI can confirm that the patch in #12 fixes the bug in the original post. Patch looks very sane to me. Sorry for unintentionally hijacking the issue.
Comment #15
dave reidMore complete patch with a version with tests modified and tests unmodified to test that this should be expected to fail.
We had a problem with our entity field tests - we created a new controller class for an entity type that did not have a bundle column - which is wrong. DrupalDefaultEntityController is perfectly capable of working with entities that have no bundle, just like user and file entities already.
Comment #16
dave reidThis time without the unrelated changes.
Comment #17
dave reidAnother LOL discovered by this patch - all our test entities were using 'name' => t('Name of entity') and not actually using the correct key of 'label' which causes a crap-ton of PHP notices locally but doesn't seem to come through from the testing bot.
Comment #18
dave reid#16: 1054168-efq-entities-no-bundle.patch queued for re-testing.
Comment #20
dave reidOfficially needs review now.
Comment #21
dave reidComment #22
bojanz commented#16 still applies to D7 and makes sense.
+1 for RTBC.
Attaching a reroll for D8.
Comment #23
bojanz commentedMaybe the bot is ignoring the patch because of the "-d8" prefix in the filename? Let's try again.
Comment #24
bojanz commentedUpdated comment.
Comment #25
chx commentedLooks good.
Comment #26
damien tournoud commentedfield_sql_storage_field_storage_query()can also filter by bundle, and currently builds the entity/property part of the query itself. We need to refactor it so that it usesEntityFieldQuery::propertyQuery()instead.Tests also need to be extended to cover queries that have entity_type+bundle+field conditions.
Comment #27
dave reidSounds like a good follow-up to me. Can we just get the bug fix in?
Comment #28
damien tournoud commented@Dave Reid, you misunderstood: the same bug issue around bundles likely applies when there is a field condition:
Comment #29
ParisLiakos commentedhere is an issue, i believe is the same problem
#1511132: Database error when creating a new list
Comment #30
chx commentedEntityFieldQuery has been removed from D8.
Comment #31
damienmckennaUnassigning it to imply anyone can pick it up.