Child pages
  • [deployment] Meta-command support in deployment script
Skip to end of metadata
Go to start of metadata

Imported From:

In In-Portal 5.1.3 new deployment script functionality was developed. It allows to:

  • specify revision-based database queries
  • revision dependencies

After missing (revisions that weren't executed before) are executed these actions are performed:

  • resets caches
  • import language pack

This very powerful already, but it missing ability to execute a revision-specific php code.

I see this as a meta tags, placed inside a comments, like this:

# {namespace:meta_tag_here}

There also can be several meta-tags per line. When processed we'll scan all registered namespaces and then ask them to process meta tag.


  1. Yes, we definitely need some improvements, but how would the the PHP file
    with namespaces / meta-gats look like?

    I am not quite sure I follow the format here.


  2. It still will be SQL file. Command format as I've described before, but I'm
    not quite sure how to manage which code will process which command yet.

  3. I think we can continue researching and discussing on this.

    In the end we want to be able to evoke some PHP code from
    project_upgrades.sql file so it can manipulate data with some Business
    Logic rather plan SQL as we do now, correct?


  4. Yes, but without typing a PHP code right in SQL file.

    Maybe we can start with simple implementation without fancy {{ and }} tags
    first. For example we'll call OnDeploy event from prefix, associated with
    module, which project_upgrades.sql is being pressed before and after each
    revision processing. A revision number and invocation place (before or
    after) will be given as parameters to an event.

    How about that?

  5. Sounds interesting and quite similar to what we have for In-Portal upgrades
    right now - which is good.

    I say we need to have 1 general "OnDeploy" associated with module, which
    project_upgrades.sql which can they call another customer methods from
    inside. To make it clean and easy to understand I would have a separate PHP
    file which will store base "OnDeploy" and then custom Methods created by
    developer that are called from within "OnDeploy" (via switch case or

    Am i going too far?


  6. Not sure if having a separate file (event handler) is possible, since we
    already have one (e.g. "custom-sections", "p", "l") associated with each
    module and I was planning to re-use it.

    If you in turn plan to create a separate event handler (and corresponding
    unit) in each module, then please explain unit prefix naming scheme, since
    unit prefix must be unique in each module.

  7. I guess I wasn't clear enough here.

    But I think we need to make it as straight forward as possible. I like the
    idea how it's done with In-Portal upgrades when you can have a separate
    method for any upgrade so here it might a good idea too to add similar
    (associate with revision number) + call it whenever needed using Meta
    format you suggested.


  8. I see, you mean a separate class, like InLinkDeploymentHelper,
    CoreDeploymentHelper, CustomDeploymentHelper and so on.

    Sad that we can't actually extend it from kDeploymentHelper, but get the