I've had an idea for a way of joining up Features and Migrate in order to export entities that are data rather than config. I'd be interested in what people think...
The background is that lately I'm working on a project where we have several taxonomy vocabularies that are more part of the site structure than really content, so I used the Taxonomy CSV module to export them to CSV files and wrote a quick custom module with a UI to import them back in, so our various developers could use them to get test sites up to speed.
Then lately I've been working a lot with Migrate module, importing large CSVs of Commerce Product data.
That got me thinking that I could have used Migrate to have the taxonomy CSVs imported. Which in turn got me wondering whether this could be joined up with Features.
Because after all, Features is made up of two pieces of functionality:
- some code in a file, that a given module knows how to turn into data in the database
- a way of taking data in the database and turning it into the code.
Migrate module knows how to turn a CSV file into data... so the missing piece is just turning the data into CSV. And a little bit of glue for Migrate module:
- export entities to Features as hook + a CSV file, using EntityAPI metadata properties to get the data and using the property names as the CSV header
- a dynamic Migration class that reads the CSV, automatically mapping the source fields using EntityAPI metadata
- something that reads the hook written by Features to define Migrations and run them
I'm not sure how Features' concept of reverting a feature would work (re-import without rollback perhaps, to keep entity IDs the same?), but it could be a pretty neat way of exporting data entities to code.