Akelos Framework v1 forum archive. This forum is no longer maintained. To report bugs please visit https://github.com/akelos/akelos/issues
    •  
      CommentAuthorthynctank
     
    Are there plans to include a Rails-style migrations rake task-like option for bringing all migrations/installations up-to-date at the latest migration #?

    I realize that since Akelos has more granular migrations (I love the simplicity available for table installations, btw), meaning it versions things per model (numbering within each migration file) vs the entire project (by numbering individual filenames), this is a bit of a task, but if someone does choose to go down the Rails path and version the entire project as a whole, it'd be nice to say, "./script/migrate ALL VERSION=15" or something along those lines. Perhaps there could be an option in config for enabling Rails-style migrations?

    Is there a fundamental reason for the Akelos installations/migrations vs the Rails way? I'm curious to know the background on this. This is not a deal breaker by any means, just a curiosity. I haven't had to roll back to a specific version once since I started my current job working with Rails, though I'm sure it may happen at some point. Granular control such as Akelos has would provide the availability to roll back some models/data and not others, I assume that's the idea...

    There should at least be a built-in task for running through all migration files and executing every single method in order, like calling "rake db:migrate" with no parameters. Is there one I'm missing? It should be trivial to implement. Should I look into contributing such a thing? Are others interested?
    •  
      CommentAuthorbermi
     

    Hi Nick,

    Are there plans to include a Rails-style migrations rake task-like option for bringing all migrations/installations up-to-date at the latest migration #? It is not planned yet. You're welcomed to submit a ticket and a patch with this feature.

    Personally I use the attached script in one large project with 25 installers.

    I haven't added this to the trunk because I think it will be better to integrate the update into the migrate command.

    There is also one important issue that I found while using this method. If you run a batch of installers alphabetically you might find that on account_installer version 5 you have a dependency on user_installer version 1.

    Having a unified installer avoids this problem. For example, a custom installer named app_installer which will call specific versions of individual installers like:

    <?php
    
    class AppInstaller extends AkInstaller
    {
        function up_1()
        {
            $this->_installOrUninstallVersions(array(
                'user' => 1,
                'account' =>5
            ), 'up');
        }
    
        function down_1()
        {
            $this->_installOrUninstallVersions(array(
                'user' => 0,
                'account' =>0
            ), 'uninstall');
        }
    
        function _installOrUninstallVersions($installers, $direction = 'up')
        {
            foreach ($installers as $name => $version) {
                $command = AK_SCRIPT_DIR.DS.'migrate '.$name.' '.$action.' '.$version;
                `$command`;
            }
        }
    }
    
    
    ?>
    

    can be a perfect solution for application wide installers, while single installers remain isolated.

    Granular control such as Akelos has would provide the availability to roll back some models/data and not others, I assume that's the idea...

    That's right

    Should I look into contributing such a thing? Are others interested?

    I am :)

    As we don't have a rake command yet could use

    ./script/migrate all 15
    

    as you suggested, or

    ./script/migrate app 15
    

    and require an app_installer.php

    If you implement something interesting, please open a ticket, take ownership and contribute your solution as a patch so this can be integrated into AkInstaller.

    • CommentAuthorKaste
     

    this is btw ticket #90

    +1