I don't know if this will be useful to anyone. At the company I worked for they had a large distrubution running over 100 website. They were running draggableviews 1.x-dev. I created an upgrade path so the data wasn't lost when we upgraded to 2.x.

For the UI, I had to recreate the views manually then export it as a feature.

In #1 is the patch that worked for us. I do not know if it will work for you.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

iStryker’s picture

Attach is the patch. If you apply this patch to 7.x-2.x-dev, everything will work. If you apply this patch to 7.x-2.0, things will probably break because of #1662830: Wrong hook_update_N()

If I find time, I plan on adding a check for schema version and will re-roll this patch.

Again:
To test or to upgrade:

  1. Install the latest Draggableviews-1.x-dev. Run update.php.
  2. Remove draggableviews-1.x-dev code.
  3. Install Draggableviews-2.x-dev (Works as of August 8th,2012)
  4. Run update.php (should be 4 pending updates).
iStryker’s picture

Title: Upgrade Path 1.x to 2.x » Upgrade Path 1.x to 2.x (for data)
iStryker’s picture

Attached is the patch that will not break if you do a 7.x-2.0 -> 7.x-2.x-dev (or 7.x-2.0 -> 7.x-2.x).

drasgardian’s picture

Attached is a patch to also support upgrading data that has a hierarchy, i.e. uses parent field.

btw, this patch also removes the temp table used in the previous patches, because it didn't seem to be doing anything.

iStryker’s picture

Status: Active » Needs review

@dragardian Temp table is removed in 7102. If 7101 fails, there is always a temp table to go back to. If 7101 works, then 7102 gets fire, which removes the temp table.

However this is not standard Drupal practice. Standard Drupal practice is to backup database before hand, if it fails, then you restore your backup. So, your solution is better

The patch looks good to me. Maybe later this week I will get a chance to test it more.

iStryker’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
5.41 KB

Just testing upgrade of 1 to 2 with Taxonomy Hierarchy. Everything went smooth.

Steps

  • Download latest 7.x-1.x
  • Run updates (believe there is none)
  • Replace latest 7.x-2.x
  • Download and apply patch #4
  • Run updates
  • Fix your views

Upgrade script will not run if you have version 7.x-2.0, as it does a check

Now should this patch get committed? The only thing that is holding me back is the need to fix all of your draggableviews views after running the upgrade script. IMO, It is too complicated to create a script that will fix your views automatically.

I added an updated message in the attached patch:
from

+ * Upgrades the draggableviews_structure table from 1.x to 2.x (schema_version 7200).
+ * Backup your data before you run this!

to

+ * Upgrades the draggableviews_structure table from 1.x to 2.x (schema_version 7200).
+ * This will run if you have 7.x-1.x installed and are upgrading to 7.x-2.x. Otherwise
+ * this will be skipped. All of your views will need to be manually updated using the
+ * Views UI. Backup your data before you run this!:

This will get display when before you apply the pending update(s).

iStryker’s picture

Status: Reviewed & tested by the community » Fixed

Spoke with @ygerasimov. His only worry was this script might get hung on a table with thousands of rows. If anyone experience this and has trouble, please comment on issue.

Again my solution for large production is:

  1. [If not done already, create features of live sites draggableviews views]
  2. Copy live site to local dev/staging.
  3. Dev/Staging - Replace 7.x-1.x with 7.x-2.x.
  4. Dev/Staging - Run update.php
  5. Dev/Staging - Fix your views
  6. Dev/Staging - Re-Export views as a feature.
  7. Backup Live
  8. Live - put in maintenance mode
  9. Live - Replace 7.x-1.x with 7.x-2.x on Live
  10. Live - Run update.php
  11. Live - Upload new features
  12. Live - Revert your features in UI (or drush)
  13. Done - take Live out of maintenance mode

Only one difference. I push changes to private git repository, then pull them down to live. Depending on your environment, there are other [better] ways of doing this.

Committed #6 to dev. (& removed extra white-space)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.