Apex 5 Application Context

"under the hood"Just a quick note that (as mentioned by Christian Neumueller earlier) Apex 5 now populates an Application Context APEX$SESSION with the session’s User, Session ID and Workspace ID:

SYS_CONTEXT('APEX$SESSION','APP_USER')
SYS_CONTEXT('APEX$SESSION','APP_SESSION')
SYS_CONTEXT('APEX$SESSION','WORKSPACE_ID')

Using the above should be faster in your queries than calling v() to get these values. Note that the alias 'SESSION' won’t work like it does with v().

The context is managed by the database package APEX_050000.WWV_FLOW_SESSION_CONTEXT which is an undocumented API used internally by Apex to synchronize the context with the associated Apex attibutes. Incidentally, the comments in the package indicate it was authored by Chris himself.

Personally I was hoping that a bit more of the session state would be replicated in the context, e.g. application ID, page ID, request, debug mode, application items and page items.

Sidebar: to see all contexts that are visible to your session, query ALL_CONTEXT. To see all context values set in your session, query SESSION_CONTEXT. Of course, don’t query these in your application code to get individual values – that’s what the SYS_CONTEXT function is for.

5 thoughts on “Apex 5 Application Context

  1. Hi Jeff,

    we intentionally kept that list of context values small, because we did not want to duplicate data. These 3 were thought to be most useful for column default values and performance critical queries. I realize that a case can be made for additional values and we certainly can extend the current list. I once even considered adding a public API to set user-defined values (in the Initialization PL/SQL Code), but never got around to actually implement it.

    Regards,
    Christian

    Like

  2. Thanks Chris. I think the addition of the context is a great addition and it would be great to see some of the other common Apex variables added in a future release.

    I like the idea of the public API – while most PL/SQL developers can already set their own contexts, adding it as an Apex API would help those who are in environments where (for whatever reason) they don’t have the privilege necessary to create their own context.

    I would suggest that adding user-defined values would be even better if it’s done declaratively, e.g. as an optional attribute of each Apex item, e.g. “Synchronize with Application Context”. I could nominate, say, an application item to be synchronized, and then access that item via APEX$SESSION.

    Like

    1. Creating a context requires CREATE ANY CONTEXT, this should be restricted to DBAs. It’s one of the reasons why I considered such an API. I also like your idea of flagging items that APEX should automatically synchronize. That’s a nice, declarative approach.

      Like

Comments are closed.