Posted by Haza on August 26, 2011 at 2:43pm
7 followers
| Project: | Entity reference |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Damz already coded the migrate handler for entityreference. It really should be implemented in the module. (tested and approved locally, it works)
Patch by Damien attached for reference.
Comments
#1
#2
Thanks for reminding me of this. Committed.
#3
It seems that, even if migrate implement the hook_hook_info(), it doesn't trigger the class (during an import) unless I add the file in the .info of the module.
Attached here an other patch that implements the migrate plugin in an other way.
What do you think about that ?
#4
I simply added the missing reference to the file in the .info. Please reopen if this is not fixed.
#5
Automatically closed -- issue fixed for 2 weeks with no activity.
#6
Shouldn't we be allowing the type to be passed in as an argument? I'm getting the following error trying to use this:
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'field_webform_project_submission_target_type' cannot be null: INSERT INTO [error]{field_data_field_webform_project_submission} (entity_type, entity_id, revision_id, bundle, delta, language, field_webform_project_submission_target_id,
field_webform_project_submission_target_type) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3,
:db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7); Array
(
[:db_insert_placeholder_0] => webform_submission_entity
[:db_insert_placeholder_1] => 794482
[:db_insert_placeholder_2] => 794482
[:db_insert_placeholder_3] => grant_application
[:db_insert_placeholder_4] => 0
[:db_insert_placeholder_5] => und
[:db_insert_placeholder_6] => 766775
[:db_insert_placeholder_7] =>
)
(modules/field/modules/field_sql_storage/field_sql_storage.module:448)
but the problem might be in the code we're using to make webform_submissions fieldable.
#7
Here's what I had to use to get this going… did some cleanup along the way.
#8
fixed one other issue with empty values.
#9
Well, I was all set to submit my own patch adding a target_type argument, you beat me to it! Your patch works for me...
#10
There is only one type per field, so this argument should not be required at all. Can anyone explain the rationale here?
#11
If the target_type is not specified, you get the error in comment #6. But, if the target_type is common to all instances of a given field, then we should be able to just pull it from the field info, right?
#12
'target_type'is added byentityreference_field_presave(). Why doesn't that work in the context of Migrate?#13
Hmm, a good question, migrate calls node_save() so the presave hooks should be getting called... Guess some more debugging is in order.
#14
OK, my problem is that the field is defined via features, with a default value of:
<?php'default_value' => array(
0 => array(
'target_id' => '82',
),
),
?>
Features does not save a target_type. Because default values aren't fetched until after hook_field_presave(), it doesn't get fixed up. I'm not sure what the workflow is when creating features - whether there's something entityreference can declare differently to get it picked up, for example - but a quick and easy fix is to just rename entityreference_field_presave() to entityreference_field_insert().
That solves my problem, anyway, I can't speak for drewish...
#15
I'm also using fields exported as features. I didn't have time to circle back and sort this out, I just left my patch applied.
#16
Here's a patch to replace the presave hook with insert and update hooks, to make sure target_type gets set in all scenarios.
#17
@mikeryan, I think it's related -- #1319040: Remove "target_type" column from db, I think we should remove the target_type completely, as in the end ER references only a single target_type.
#18
So much the better, but there's no patch there yet. This will tide us over unless/until the target_type is removed.
#19
> but there's no patch there yet.
Now there is ;)
#20
The last submitted patch, handle_default_values-1261086-16.patch, failed testing.
#21
Target type is now gone for good.
#22
Automatically closed -- issue fixed for 2 weeks with no activity.