Posted by slashrsm on May 29, 2012 at 5:10pm
11 followers
| Project: | Relation |
| Version: | 7.x-1.x-dev |
| Component: | Relation migrate |
| Category: | task |
| Priority: | normal |
| Assigned: | slashrsm |
| Status: | closed (fixed) |
Issue Summary
It would be nice to have migrate integration. Attached patch implements destination handler. Would this better be in this module or in migrate_extras?
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| relation_migrate_support.patch | 7.4 KB | Idle | PASSED: [[SimpleTest]]: [MySQL] 283 pass(es). | View details |
Comments
#1
#2
A bit improved patch.
#3
Amazing! Love it. How could I test this? And, could you write a simpletest? We have many tests that check for the existence of a module and continue if it is there.
#4
I could write an example. I can also write tests. I do not have much experience with this, so I'd need some help here. Mostly with selection of test cases.
#5
Well I have no idea what this would be useful for as I never worked with migrate myself :) but I am sure it's very useful. Can we use this for the reference update path perhaps...? And test that.
#6
Well I have no idea what this would be useful for as I never worked with migrate myself :) but I am sure it's very useful. Can we use this for the reference update path perhaps...? And test that.
#7
I believe we could use it for that... In which stage is reference migration right now?
To give you an idea about my use-case. I have a media portal, where they have premium content. To activate premium access you get so called "premium number", which are imported daily into Drupal. When user enters premium number system checks if exists and saves this as "activation". In old system is this just a simple table connecting user and premium number. In new system, beeing developed, we use commerce_product_key for numbers and connect them to users via relation ("activation" in our case).
#8
#1053108: Upgrade path from *reference? links http://drupal.org/sandbox/btmash/1492598
#9
slashrsm: can you post an example implementation of MigrateRelationendpointsHandler? I'm using your MigrateDestinationRelation patch and unclear how to map the endpoints array here. Thanks!
#10
I finally found some time to work on this. As soon I have any noticeable progress I'll post a patch against 7.x-1.x.
Here is my development sandbox: http://drupal.org/sandbox/slashrsm/1672590
#11
Waiting for the patch. Exciting!
#12
I have already commited some things in my sandbox.
#13
Attached patch kinda implements migration plugins and migration of entityreference, user_reference, node_reference and taxonomy_term_reference fields into relation. It already implements a simple configuration form under admin/structure/relation/migrate.
What definitely still needs to be done:
- more comments, polishing, code standards, ...
- validation at configuration form (check if selected relation type supports source and destination entities at all)
- test
So please take this patch more as a demonstration and a request for feedback about basic concepts than a finished thing.
#14
#15
Hi slashrsm, this is looking very promising. I'm going to have a crack now at running a migration from CSV into Relation. Is there a handler written for the RelationEndpointsField? If not, how does that work?
#16
Unfortunatley not. I was thinking about the way to implement this, but I was unable to find a solution that would be flexible and general enough. Let me know if you have any ideas.
Anyway... I can be *really* easy implemented this way: http://drupalcode.org/sandbox/slashrsm/1672590.git/blob/refs/heads/maste...
#17
Some more work done. Now we have more validation on configuration form. The basic shape of the module is now done. We need tests. I think this is the right time to give comments about architecture, code or UI. I'd rather refactor things now than later, when we have all tests done.
Looking forward to get some feedback....
#18
Some tests added. More to come. Let's see how they behave....
#19
The last submitted patch, 1606404_migrate_integration_18.patch, failed testing.
#20
Some more tests and it passes locally. Let's try it....
#21
The last submitted patch, 1606404_migrate_integration_20.patch, failed testing.
#22
I think setUp is failing on testbot due to the missing modules. This is how it's done in relation.rules.test:
<?phpfunction setUp() {
parent::setUp('relation');
// While setUp fails for non-existing modules, module_enable() doesn't.
module_enable(array('rules'));
}
?>
#23
THX for the tip. Let's see if this fixes it.
#24
The last submitted patch, 1606404_migrate_integration_23.patch, failed testing.
#25
#26
The last submitted patch, 1606404_migrate_integration_25.patch, failed testing.
#27
Still passes locally. Let's try again.
#28
The last submitted patch, 1606404_migrate_integration_27.patch, failed testing.
#29
Let's try this....
#30
The last submitted patch, 1606404_migrate_integration_29.patch, failed testing.
#31
#32
Move the test into the relation_migrate.info and then we can commit this , and the dependencies will be picked up by the bot on dev release.
#33
OK. I did that and I also fixed some whitespace issues.
All tests pass locally. I only get one exception, which apparently happens in migrate, so I can do nothing about it. See the attached image....
#34
Committed, let's see what the test bot thinks about it. Thanks slashrsm
#35
Great. Thanks to everybody that helped with this.
Would it be reasonable to add "Relation migrate" under component drop-down?
#36
done :)
#37
Great!
#38
Automatically closed -- issue fixed for 2 weeks with no activity.