For safe team development, you should be working with files and a source control system. Subversion for example shows you incoming changes for the scenario you are describing.
We don't monitor the state of DB objects in the DB after you have opened them for performance reasons.
That behaviour is very dangerous,
The behaviour that is 'dangerous' is your own orgs procedures.
Your org is NOT following best practice for software development in a team environment
1. Official code should be in a version control system.
2. Developers should use their own dev schema when doing development and unit testing. This alone totally prevents the scenario you describe in this post
3. Any developer making an 'official' change - that is, not one just for dev and further testing - should:
a) copy (not check out) a version of the ddl from version control to their pc
b) make any desired changes to their copy in their own dev schema and test them
c) after testing check out and lock the official version from version control
d) verify that either the official version has NOT been changed while they did their own dev and testing or that changes made do NOT intersect with the changes they are making
e) make their changes to the official, checked out version of the code, adding comments indicating the WHO, WHAT and WHERE of their changes
f) check back in, and unlock, their modified official version
Note - the user making changes does NOT actually change the 'official' code version even in Dev. That is done by a developer assigned to that task, often in a round robin fashion so that other devs turns migrating changes from version control to the actual environment.
I suggest you solve your problem by convincing your org to follow BEST PRACTICE as outlined above.
You say it's a dangerous behaviour, you're talking about the people doing that, right?
It's been said already, but you must use a source control system, such as SVN or Git. You can't rely on a dev DB to be a source repository. What if it crashes? How do you keep track of fixes?
That behaviour is not new. So it is not a "new bug" that was introduced in 18.1. Instead it is a behaviour that existed for a long time already (proabably forever).
For all the good advice on best practices, I am with the OP on this one.
I do not remember noticing this behaviour before, probably because code i was re-opening had not been affected by anyone else so re-opening a locally cached copy of my own latest changes was OK.
> (3) After that, user A closes the package and opens it again.
I can understand caching meta-data so browsing db objects is fluid (hence having to occasionally refresh a list in order to see objects newly created by others), but the object itself not being fetched from its live version sounds to me like aggressive optimisation.
How then is caching working ? Only across a work session (e.g. i will not get cached data if i have closed sqldeveloper in-between) ? Does it apply to all object types ? Will I see columns a colleague added to table i have been working on only after an explicit refresh (just an example) ?
We only do a refresh after you use the Edit object dialogs or do a compile...I think.
And like others have said, it's always been this way.
If CQN worked on data dictionary objects, we could afford to do instant refrshes, but it doesn't so we don't.
Just because it has always been so does not mean there is no room for improvement - otherwise nothing would ever get improved, right ?
Oh well, so much for the principle of least surprise.
Out of curiosity what does CQN stand for ?
Just search for 'oracle 12c cqn' and read the doc at the first link
Ah alright, thanks rp0428.
You can define a query and ask the DB to tell you when the results change. But its not available for data dictionary views.