Closed (fixed)
Project:
Relation
Version:
7.x-1.x-dev
Component:
Relation migrate
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
29 May 2012 at 17:10 UTC
Updated:
20 Aug 2012 at 18:51 UTC
Jump to comment: Most recent file
It would be nice to have migrate integration. Attached patch implements destination handler. Would this better be in this module or in migrate_extras?
| Comment | File | Size | Author |
|---|---|---|---|
| #33 | test_pass.png | 2.32 MB | slashrsm |
| #33 | 1606404_migrate_integration_33.patch | 45.71 KB | slashrsm |
| #31 | 1606404_migrate_integration_31.patch | 45.24 KB | slashrsm |
| #29 | 1606404_migrate_integration_29.patch | 44.95 KB | slashrsm |
| #27 | 1606404_migrate_integration_27.patch | 44.92 KB | slashrsm |
Comments
Comment #1
slashrsm commentedComment #2
slashrsm commentedA bit improved patch.
Comment #3
chx commentedAmazing! 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.
Comment #4
slashrsm commentedI 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.
Comment #5
chx commentedWell 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.
Comment #6
chx commentedWell 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.
Comment #7
slashrsm commentedI 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).
Comment #8
chx commented#1053108: Upgrade path from *reference? links http://drupal.org/sandbox/btmash/1492598
Comment #9
andyhawks commentedslashrsm: can you post an example implementation of MigrateRelationendpointsHandler? I'm using your MigrateDestinationRelation patch and unclear how to map the endpoints array here. Thanks!
Comment #10
slashrsm commentedI 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
Comment #11
chx commentedWaiting for the patch. Exciting!
Comment #12
slashrsm commentedI have already commited some things in my sandbox.
Comment #13
slashrsm commentedAttached 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.
Comment #14
slashrsm commentedComment #15
rlmumfordHi 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?
Comment #16
slashrsm commentedUnfortunatley 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...
Comment #17
slashrsm commentedSome 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....
Comment #18
slashrsm commentedSome tests added. More to come. Let's see how they behave....
Comment #20
slashrsm commentedSome more tests and it passes locally. Let's try it....
Comment #22
mikran commentedI think setUp is failing on testbot due to the missing modules. This is how it's done in relation.rules.test:
Comment #23
slashrsm commentedTHX for the tip. Let's see if this fixes it.
Comment #25
slashrsm commentedComment #27
slashrsm commentedStill passes locally. Let's try again.
Comment #29
slashrsm commentedLet's try this....
Comment #31
slashrsm commentedComment #32
chx commentedMove 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.
Comment #33
slashrsm commentedOK. 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....
Comment #34
mikran commentedCommitted, let's see what the test bot thinks about it. Thanks slashrsm
Comment #35
slashrsm commentedGreat. Thanks to everybody that helped with this.
Would it be reasonable to add "Relation migrate" under component drop-down?
Comment #36
mikran commenteddone :)
Comment #37
slashrsm commentedGreat!