Hi,
In includes/base.inc, there is
protected MigrationBase::generateMachineName(), and
protected static MigrationBase::machineFromClass($class_name)
The logic is to build the machine name from the class name.
Classes are to be named like "BlaBlaMigration".
I would much prefer to give my custom module classes a prefix, to be safe against nameclashes.
Typically, my classes are named like this:
class my_module_MyClass_Whatever
For my own migrations, I decided to use class names like
class my_module_Migration_Node_FaqItem.
Unfortunately, this would give me very long machine names. So I tried to override the generateMachineName, to give me machine names like
Node_FaqItem for class my_module_Migration_Node_FaqItem.
The bad thing:
machineFromClass() is sometimes called directly, and not from generateMachineName(). The object is not created.
In particular, that's MigrationBase::registerMigration() that is doing this.
Solution
Pretty easy, in includes/base.inc, there are two places that need changing. New way to call machineFromClass is
call_user_func(array($class_name, 'machineFromClass'), $class_name)
Then those who care can override machineFromClass.
This works fine, except that migrations appear not nicely sorted.. I guess we can live with that.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | migrate.machineFromClass.7-x-2-x.1386458-1.patch | 1.13 KB | donquixote |
| #1 | migrate.machineFromClass.7-x-2-x.1386458-1.patch | 1.11 KB | donquixote |
Comments
Comment #1
donquixote commentedAnd here's a patch...
Comment #2
donquixote commentedSmall fix for the patch.. "self" does not resolve to a string.
Comment #3
mikeryanHow about just declaring your migration classes as dynamic (i.e., derive from DynamicMigration rather than Migration, or for a MigrationBase add an isDynamic() definition returning TRUE)? Then explicitly register classes with MIgrationBase::registerMigration($class_name, $machine_name).
Comment #4
donquixote commentedI need to study this dynamic migration part..
They need to be registered and unregistered explicitly during install and uninstall, right?
So far, I am using the patch above and it works fine. Have my classes folder organized somewhat like psr-0.
EDIT:
Also, with dynamic migrations, what do I need to do if I want to add new classes or rename and modify, do I need some hook_update_N, or is this detected automatically?
I am looking at
http://drupal.org/node/1006998 "Dynamic migrations" and
http://drupalcode.org/project/wordpress_migrate.git/tree/refs/heads/7.x-1.x
can't see the place where stuff is registered or unregistered.
Comment #5
mikeryanDynamic migrations are not automatically detected, they must always be registered explicitly. One way to do it is in hook_install(), adding new ones in hook_update_N(); but what I've been doing is handling it in hook_flush_caches(), which is a bit more dynamic. Note that there's no harm in calling registerMigration for a migration that's already been registered.
Comment #6
mikeryanI will note that I'm thinking in the next evolution of Migrate (API version 3) of dropping the auto-registration based on class names and just making Migration "dynamic", requiring explicit registration. The autoload stuff is kind of fragile, particularly on D6 with the contrib autoload module, and adds a lots of overhead in hook_flush_caches.
Comment #7
donquixote commentedThe auto detection is quite practical during development :)
And migrate modules are "during development" most of the time..
Actually it works quite well for me (after adding the abstract and base class check). Ok, this can result in orphan migrations.. but this can be dealt with.
For the overhead, I don't see how this is worse than any other autoloading class.
(Btw, for my own use I made a module where you just write
files[] = lib/**/*.incin the info file, and it will scan all of the lib folder..Even better would be a psr-0-like autoload. I even consider writing such a thing, once the guys agree on a standard for Drupal 8 :)
#1290658: Move all module-provided classes to PHP namespaces (PSR-0 or similar), and autoload them without the registry [policy, no patch]
Comment #8
mikeryanThe original request, customizing machine_name, is already supported by using DynamicMigration with registerMigration().
Comment #9
donquixote commentedHm, I'm not really happy.
Dynamic migration is less convenient, afaik. And the patch would be really simple.