Posted by Paul Kim Consulting on October 11, 2011 at 1:17am
6 followers
| Project: | Mongodb |
| Version: | 7.x-1.0-beta2 |
| Component: | Field storage |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
MongoDB does not work with custom fields with these revisioning modules:
http://drupal.org/project/revisioning
http://drupal.org/project/workbench_moderation
As far as I can tell, this is a bug in mongo_field_storage_field_storage_load(). It seems to be trying to match the revision id instead of node id. But I am not sure of the fix.
Comments
#1
I've fixed this by changing
<?php$entity_id = $row['_id'];
?>
In mongodb_field_storage_field_storage_load() to
<?phpif ($row['nid']) {
$entity_id = $row['nid'];
}
else {
$entity_id = $row['_id'];
}
?>
#2
Pacth for the above fix.
#3
#4
The last submitted patch, revision_modules-1305580-2.patch, failed testing.
#5
#6
Could somebody test if this patch works, so we could put in dev?
#7
Committed to the latest dev.
#8
I'm reopening this for two reasons:
1. The provided fix causes bug #1497456: Field Storage: undefined index: nid in hook field_storage_load
2. It totally breaks (for example) comments' fields. This is because comments have a field named 'nid'! Consider what happens when that is used as $entity_id in the loop. Right, bad things.
I'll try to come up with a patch that would provide best of both worlds. In the meantime, I strongly suggest NOT using this patch (nor the current dev version).
#9
Here's my suggestion for a patch. This one doesn't break comments and doesn't throw notices. I do not know if it still serves its original purpose but I can't see any reason why it wouldn't. I'm a bit unsure whether any field other than _id in any type of result should ever be considered the entity id. For revisions, _id probably equals vid, the same way _id equals nid for current nodes? Isn't this desired? (I might be completely wrong here, since I'm not familiar with revisioning or workbench_moderation modules).
#10
#11
The last submitted patch, revision_modules-1305580-9.patch, failed testing.
#12
#13
Sorry, the previous patch was for 7.x-1.x-dev. This one's for the version actually mentioned in the issue.
#14
Now I accidentally changed the version... Seems I'm causing more harm than good.
#15
#16
Thanks, committed to the latest dev.
#17
Automatically closed -- issue fixed for 2 weeks with no activity.