-
Notifications
You must be signed in to change notification settings - Fork 120
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
Comments
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. |
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. |
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. |
How about preferences, levels by scope? |
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. |
That is a clever way to do it, @eaolson. Here is what I am thinking as a solution in Logger code: Then, the tool would check for preferences in this order: For other types of programs, like Oracle Forms, I would set the scope as the name of the program. |
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. |
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,
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
The text was updated successfully, but these errors were encountered: