Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preferences by Context #189

Open
felmadruga opened this issue Oct 21, 2016 · 7 comments
Open

Preferences by Context #189

felmadruga opened this issue Oct 21, 2016 · 7 comments

Comments

@felmadruga
Copy link

I work in a rich environment for PL/SQL developers. We have Oracle Forms, Oracle APEX, Java that calls PL/SQL, PL/SQL batch jobs, etc.

For us, it is necessary to set logger preferences by a key other than the client_identifier. For example,

  • Name of the Oracle Forms App
  • Oracle APEX Application ID and Workspace Name
  • Name of a package
  • Arbitrary name set on a transaction

I am calling this a context_identifier. It could be set automatically or with a call like log_set_context.

The tool would check for preferences in this order:
client_identifier preference > context_identifier preference > system preference

@felmadruga
Copy link
Author

I would like to give an example, to make my point clearer.

We have several APEX apps. If we launch a critical app, I would like to set a high level of logging for only that application, in the first week.

At this time, I can't do that. If we increase the level, we do it for all apps or for a specific session.

@jeffreykemp
Copy link

I wonder - if we want a higher level for a particular app, can't we just add code to the app itself to increase the logging? Could be added as an application process run On New Instance. You can even put a condition on it so that it stops running after a particular date.

@felmadruga
Copy link
Author

I believe we would be (re)implementing something that is a concern of the logging tool. Do something with potential reuse inside the app also does not sound like the best way to do it.

Here we have 179 APEX apps. If users start to complain about a certain app, it would be useful to increase logging on that particular app, temporarily. I could want more logs for recently updated apps, any app.

Also, it would be useful to have this column (APEX app ID) on the logs views and tables.

@felmadruga
Copy link
Author

How about preferences, levels by scope?

@eaolson
Copy link

eaolson commented Oct 31, 2016

I actually do something like this already. I have a table that lists all applications and an app-specific debugging level. An application process runs on each new Apex instance that checks this level and changes the Logger level if it's different from the global default. A small Apex app lets me change the application debugging levels on the fly.

I'm not sure if this could be implemented easily in Logger itself, because I'm not sure how you could create that On New Instance application process programmaticly.

Another part of that custom Apex app lists all Apex sessions and lets me set a client-specific logging level. That's not as useful as I originally thought, just because I usually find out about problems well after the fact and debugging that way doesn't help much.

@felmadruga
Copy link
Author

That is a clever way to do it, @eaolson.

Here is what I am thinking as a solution in Logger code:
A function like get_apex_scope() that returns "workspace.app_id" on APEX.
A table exactly like logger_prefs_by_client_id, but called logger_prefs_by_scope.

Then, the tool would check for preferences in this order:
client_identifier preferences > scope preferences > system preferences

For other types of programs, like Oracle Forms, I would set the scope as the name of the program.

@andyhardy
Copy link

I'd also like to second the idea of applying a level for a package. In our case, when someone says "there's an issue with the inventory calculation" - I'd like to be able to place just that package in debug mode, I'm not interested in any other debug (e.g. the utility functions that it calls, etc.), I'm just trying to watch the flow through this single package.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants