Question

Photo of Scott Conger

1

Migration Order across Multiple Projects

1

Is there a way to control the order that the migration are executed across projects within the same solution?  For example, we have the File Document Project/Migration that needs to be run before our Pastoral Concerns Project/Migration.  I know there is a migration number but that seems to only apply to the same project, not across projects.

  • Photo of David Stevens

    0

    Our instance always runs project migrations in alphabetical order.   If renaming the project wouldn't work, you could always insert the project.dll one at a time on your webserver.

    If you plan on releasing this plugin to the Rock store, I'd recommend checking existence of the required fields.   If you're not releasing it to the store, then why not just combine them?

    • Scott Conger

      Scott Conger

      Eck! I was hoping you weren't going to say that. ;p


      Those are the only two solutions I could come up with, as well. These two project would hopefully end up on the Rock store. So, combining them is not an option. Renaming them seems problematic. Meaning, naming them A_FileDocument and B_PastoralConcerns only works today. When the next dependency happens, it might need to be A_FileDocument, B_ProtectionApp, C_PastoralConcerns. Instead, we'd have to start a naming conversion like 010_FileDocument, 020_PastoralConcerns. So, that the next dependency would be 015_ProtectionApp.


      We have approximately a dozen projects. There is several dependencies.

      • Scott Conger

        Scott Conger

        I'll put a suggestion in the black book because it gets more complex when you think about Rock store distribution. The File Document is a component that other churches may use or even develop against. If their migration becomes dependency on it, even renaming our project doesn't help. The full project name would be org.xyzChurch.010_FileDocument. Even if they followed the naming convention, their project would be named org.abcChurch.020_PersonDocuments. Their church's name is alphabetically before ours, so the dependency would fail.

        • Scott Conger

          Scott Conger

          David, thanks for sharing your thoughts. I appreciate it. I put a suggestion in the black book.


          I also decided to took a look at Rock's reflection code. It uses AppDomain.CurrentDomain.GetAssemblies(), assembly.GetReferencedAssemblies() and pluginsDir.GetFiles(). GetFiles does not guarantee a specific order and Rock does not explicitly sort the results. MSDN is sufficiently vague about the other two. But I am left assuming they do not guarantee the sort order either. GetAssemblies is most likely in the order they were loaded. GetReferencedAssemblies is most likely in the order they were referenced. Meaning, though they are often in alphabetic order, it's not guaranteed.


          So, other than cramming everything into one giant migration script, I see no good option. And cramming it into one giant script, makes it unsharable.

          • David Stevens

            David Stevens

            I guess I don't follow why one plugin would be dependent on another. IMO a plugin should be self-contained and either check for the existence of fields (like fields that ship with core) or create its own fields to use. It's definitely more development work, but makes for a better admin experience.