Hiya,

I'm currently working on a project for a client who is currently running a Drupal 6 website running Ubercart. They want to migrate over to Drupal 7 and possibly use the migrate (and consequently since it would seem to fit) the commerce migrate module to migrate over the store products (and customer profiles and so forth). However, his D6 node types currently have other fields (primarily taxonomy) attached to them as well. And based on the recommendation from Randy's blog post and videocast, you are recommended to *not* have any of the commerce migration bundles on your site (you let CommerceMigrateUbercartProductTypeMigration discover the product types and then the dynamic migration takes over). So I wanted to ask what is the best approach to creating the bundles? Should migrate find the product types, you create the fields, taxonomy, etc for the bundles, and then perform a migration (how does commerce_migrate pick up on the custom fields and/or how do we inject in that set of data?) or should we be creating the bundles in the first place and then implement migration classes that effectively copy/paste what is in product.inc and product_node.inc (but also map out the additional fields)? Any help on clearing this up would be MUCH appreciated :)

Comments

BTMash’s picture

It *seems* like there may actually be a third option from what I am seeing. I didn't realize this but migrate actually allows you to create migrations with the DESTINATION containing the source. This is based on what I'm seeing at [#1117454]. I'm not yet sure how to fully implement it (or maybe what @chrisivens wrote is as simple as what you need to do) but if it actually works, then you could actually use commerce migrate to bring in all your content, and then create secondary destination migrations for the various types of content / products to update whatever sets of fields are necessary. The only part I am fuzzy on is how a rollback works in this scenario.

BTMash’s picture

Status: Active » Fixed

I want to do a followup on this issue. I opted with going with the secondary migration route as partially outlined in http://drupal.org/node/1117454 and it works wonderfully (I am currently doing this for the product display). You write out your migration like it was a regular migration (in my case, since I was working with the product display, I ended up copying a huge chunk of what is happening in product_node.inc from commerce migrate into my own class. But you add in 3 lines in your __construct() method:

$this->dependencies = array('CommerceMigrateUbercartNodeNODETYPE');

This ensures that your product displays are migrated in before processing this particular migration.

$this->systemOfRecord = Migration::DESTINATION;

In essence, this notifies Migrate that you are going to be strictly updating content; nothing more.

$this->addFieldMapping('nid', 'nid')->sourceMigration('CommerceMigrateUbercartNodeNODETYPE');

This line will likely change for some people. Its going to map the nid table as dependent on the value that exists from the CommerceMigrateUbercartNodeNODETYPE migration.

So...extending migrations done via commerce migrate is easily doable!

BTMash’s picture

I finally had a chance to test this out and ... turns out that there is currently an issue in migrate that actually makes using a system-of-record approach not possible. The issue stems from files (well...hopefully just file fields) being saved to an entity; this is actually causing a secondary issue where the build array from migrate fails and entities (this includes commerce products) cannot be saved with additional content in a secondary migration. I've opened an issue at #1445956: Field issues with systemOfRecord = DESTINATION if anyone wants to take a look.

BTMash’s picture

Status: Fixed » Active

I'm reopening this issue because I ended up running to a nasty bug while doing the system-of-record migrations (I haven't tried with the entity destinations migrate module, though I have a product display that seems to be working fine) implements but I encountered it first in products). When I created the migration of the secondary information, all of that information came in; HOWEVER, the fields from the initial import (field_image, commerce_price) got wiped out. The looked at what is happening in the import function and the basic gist of it is...the entity fields somehow get wiped out during the prepare() function. The real nasty part of this bug is that trying to load the entity using commerce_product_load ended up in still showing the version of the entity that had lost the data (it seems like the entity gets shared and is *not* a clone?). I got around it in my module by essentially doing a commerce_product_load to get the product object the prepareRow() function of my class and then cloning it so I had a version that was not pointing to the original. Then in the prepare() function in my class, I replaced the commerce_price and field_image fields with that contents in that original entity. That kept the data from being lost.

I'm posting this here so we can figure out what is happening that is causing the loss of data in the first place and maybe fix it. Like I said, I don't know if this belongs in migrate or here so feel free to move as necessary.

dwkitchen’s picture

Project: Commerce Migrate » Commerce Migrate Ubercart

Moving this to Commerce Migrate Ubercart

Anonymous’s picture

Issue summary: View changes
Status: Active » Closed (cannot reproduce)

The 2.x branch works differently so I don't think this is an issue anymore.