Inspired by #1152732: Define assertions on the data source...

It would be good to support reporting on the available data, along the lines of the analysis Table Wizard did - for each field, what range of values it has, what range of string lengths, how many values are present, etc. Maybe an --analyze option on drush migrate-import, which would trigger calling $this->analyze() instead of $this->destination->import()? Default implementation would do some basic stats, override to add more complex stuff specific to your application.

Thinking about it, it'll be real easy to add the basic support, and I've got some past analysis code I've written I can throw into the default analyze()...

Comments

moshe weitzman’s picture

moshe weitzman commented

I would add this as a separate drush command. Perhaps a separate module within migrate as well. It is kind of exotic.

Niklas Fiekas’s picture

Niklas Fiekas commented

Subscribe.

FrequenceBanane’s picture

FrequenceBanane commented

subscribe

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented
Component: Code » Drush
Status: Active » Fixed

Well, looking through the queue this week for low-hanging fruit to add to Migrate 2.4, I decided to table this one. But today I had some obscure CSV files to develop a migration from, with a funky escape character that means I can't import them into Excel to work out what's in them. So, I've implemented the migrate-analyze (maz) command, which for any specified migrations will list the source fields (post-prepareRow()) and tell you whether they're numeric or string, what the value or string-length ranges are, list some sample values (or all distinct values if the list is short, as when you're dealing with status codes and the like). I'm sure it could use some tweaking, and we'll think of more analyses to perform, but please open fresh issues for those.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented

FYI - the initial commit didn't work for XML migrations (where the source values don't get populated until applyMappings()), I've just committed a fix for that.

Status: Fixed » Closed (fixed)

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