static context should be applied to runtime context

[drewfish]

In the contextualizer middleware, the static context (the context given when the app was started) was not reflected in the runtime context available to the middleware (or to controllers as well). This static context should be added into the runtime context. Also, it should have higher precedence (override) than any runtime context.

[caridy]

what if we do this when dispatching a new mojit (right before expanding the instance), or doing it right inside the store method to expand the mojit instance.

[caridy]

I think we solved this a while ago. /cc @lzhan @imalberto

[aljimenez]

I just noticed that Drew had mentioned this issue before me. Pull request #1378 addresses this, although the request's context takes precedence. I think the req's context should take precedence because I see it as a more specific context than the static context. This allows the static context to serve as the default set of dimension values which can be overwritten by a request.

[drewfish]

Does that mean that I can add ?environment=production to a query parameter and hit the production database (even on a staging server) ?

[aljimenez]

The contextualizer middleware doesn't set the req's environment based on a query parameter: https://github.com/yahoo/mojito/blob/develop/lib/app/middleware/mojito-contextualizer.js#L148. It only does so for dimensions such as lang, site, device, and region. If we make the req's context take precedence we can, for example, have a default value for "site", set at start up, which can be overwritten by a request. If we make the start up context take precedence, then a developer might, for example, set a device value at startup and then the request wont be able to overwrite it.