The schema will change completely from 6.x-2.x to 7.x-2.x because of the need for entity support in 7.x.

This task is to write the upgrade path. Probably this will not be done by me, but I will be happy to review & commit patches once the 7.x-2.x branch has a dev release.

Comments

EvanDonovan’s picture

Probably this would not be a direct database write, but rather leverage the API itself (ctools exportables). That would require a 6.x compatibility layer possibly.

EvanDonovan’s picture

Since the fields columns is serialized this might require CTools exportables. Some of the other schema changes would have to be made as database writes. Sometime in the next few weeks I'll try to document the changes to make it easier for someone to potentially write this.

EvanDonovan’s picture

Wrote a description of how to port: http://drupal.org/node/1214012.

EvanDonovan’s picture

There could be a temporary table created with the old data, the data dropped on the regular tables, the schema altered, the data loaded from the temp tables, and then written into the tables according to the new schema. I think that would be the easiest way. It would be somewhat like the Views 1 to Views 2 upgrade, except simpler.

EvanDonovan’s picture

The main thing is that the value in the drupal column would sometimes need to be split - i.e., "node_page" would be drupal_entity: node, drupal_bundle: page.

EvanDonovan’s picture

Also salesforce_field_map should be renamed to salesforce_fieldmap, or else the data moved into it.

EvanDonovan’s picture

Status: Postponed » Active

I'm making this active again, since I just released the first alpha, though I don't intend to work on it currently.

kostajh’s picture

Status: Active » Postponed

In my opinion, this does not need to be done. I think most larger Drupal upgrades from 6 to 7 are happening using the Migrate module. Perhaps a better use of time would be adding Migrate support for the Salesforce Suite in Drupal 7.

kostajh’s picture

Status: Postponed » Closed (won't fix)