I've started work on the 2.0 branch that should allow for more flexible building of configurations. Here are the changes that I see that need to take place on the database level in media_mover_api.module
* rename media_mover_configurations to media_mover_steps - This helps clarify that each of the configurations steps is stored as a specific row
* rename media_mover_steps.verb to media_mover_steps.step - This moves away from the concept of "verb" and to steps for each part of the configuration
* add media_mover_steps.name - Gives each step in the configuration a specific name
* rename media_mover_config_list to media_mover_configurations - The current name is not very descriptive of what the table does.
Comment | File | Size | Author |
---|---|---|---|
#10 | mm_upgrade.tgz | 4.11 KB | darrick |
#5 | 428854.patch | 3.4 KB | darrick |
Comments
Comment #1
arthurf CreditAttribution: arthurf commented* Rename media_mover_files to media_mover_file_data
* Add media_mover_files
* Move each media mover files to separate rows in the media_mover_files table
Comment #2
mfbSubscribe
Comment #3
arthurf CreditAttribution: arthurf commentedSome additional items
* generate sids for steps
* generate cids for configurations
* build the step maps for each of the existing configurations
* strip out extra file data
Comment #4
Mark TrappTagging.
Comment #5
darrick CreditAttribution: darrick commentedI didn't get far with trying to update. But I did start writing a patch.
A couple things missing from above:
* ALTER TABLE media_mover_steps ADD `sid` VARCHAR( 255 ) NOT NULL COMMENT 'Step machine name ID' FIRST
* ALTER TABLE media_mover_steps ADD `action_id` VARCHAR( 255 ) NOT NULL AFTER `module`
* ALTER TABLE media_mover_steps CHANGE `configuration` `settings` MEDIUMTEXT CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL
* Add media_mover_step_map
Comment #6
arthurf CreditAttribution: arthurf commented@darrick thanks for starting to work on this. Here is some proto-code for doing this programatically to make sure that the correct data gets moved over. I think this could serve as the basis for getting this done
Comment #7
darrick CreditAttribution: darrick commented@arthurf I've updated your code and ended up with this. MM_OMP is my own module.
Comment #8
arthurf CreditAttribution: arthurf commentedThis looks good to me- do you want to patch media_mover_api.install so we can have other people start testing this?
And, thanks again for all the patches and the effort- it's *great* to get some support
Comment #9
darrick CreditAttribution: darrick commentedI can start working on that. One option I was thinking about other then patching the install was to create a seperate mm_migration module. As it seems like a awful lot of work for the update to be doing.
Updating the db and backing up the tables could be done in install but the migration of configurations might be better in the mm_migration. I would imagine the migration would take a very long time and a separate module would allow it to be done in batches of 100 or so. I could also see issues crop up where the user would need to be asked how best to migrate the configurations.
Either way with all the patches I've done the past few days I do have a better understanding or the new API. One thing I'm unsure about is how to fill the data array for the new files. My code above was just splitting the old mm_file into 4 mm_files. One for each step. I don't think this is correct. I should be taking the one file and then creating a data array for it for the different steps it has gone through. I have no clue what to do if the filename has changed. Do I just create a new file entry with the old_name as source_filepath and the new name as filepath and then continue the steps in this new entries data field?
BTW: I'm happy to help. My goal is see v2 get done because I would like to see a version for D7.
Comment #10
darrick CreditAttribution: darrick commentedI've ended up with a separate module for migration. My reasoning being:
- Easier to debug the migration. You don't have to keep resetting mm db_version or manually remove broken configurations previously migrated.
- I put in two drupal_alter functions:
-- One to alter the data of the old_configurations. i.e. I'm splitting up older storage step into a new storage and complete steps.
-- The other is to alter the build array when mapping old steps to new steps. i.e. I'm moving some of my custom steps to the newer mm_node steps.
Here's some examples of how I'm using the hooks:
- Currently there is a break in the recursion for migrating files. So only one file is migrated per conversion.
- The module only migrates files which are in the complete state.
- I found hook_media_mover_file_save_alter useful for cleaning up my filepaths during migration.
- I found hook_media_mover_step_save_alter useful for mapping some of the older step settings to the new step settings.