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.

Comments

donquixote’s picture

Status: Active » Needs review
StatusFileSize
new1.11 KB

And here's a patch...

donquixote’s picture

Small fix for the patch.. "self" does not resolve to a string.

mikeryan’s picture

Status: Needs review » Postponed (maintainer needs more info)

How 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).

donquixote’s picture

I 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.

mikeryan’s picture

Dynamic 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.

mikeryan’s picture

I 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.

donquixote’s picture

The auto detection is quite practical during development :)
And migrate modules are "during development" most of the time..

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.

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/**/*.inc in 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]

mikeryan’s picture

Status: Postponed (maintainer needs more info) » Fixed

The original request, customizing machine_name, is already supported by using DynamicMigration with registerMigration().

donquixote’s picture

Hm, I'm not really happy.
Dynamic migration is less convenient, afaik. And the patch would be really simple.

Status: Fixed » Closed (fixed)

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