Synonyms are well understood and commonly used objects that get downright “quirky” when dealing with editions, so I wanted to devote an entire post just to them. We like to think of a synonym like an alias, shortcut or symbolic link (to borrow terminology from various OS’s). In principle, they do operate like that, but in order to properly track dependencies on the synonym and the object it resolves to, Oracle does a great deal more under the covers.
If owned by a schema that is edition-enabled, the synonym automatically belongs to the edition in which it is created. Internally, that means it is tagged with that edition name (as are all editioned objects). A basic rule for editioning is that only another editioned object can have a dependency on an editioned object. Non-editioned objects can exist in the dependency tree for an editioned object, but only as far up as the first editioned object. It makes sense if you consider that a non-editioned object cannot identify with an edition and so multiple copies of a parent object could all be considered equally valid. There is no way to determine for sure which edition of the object to use. One could assume the default edition, but that could change with a single command and cause all the non-editioned objects to resolve to a (potentially) different object version. Rather than try to deal with that messy situation, Oracle made a rule that no non-editioned object can point to an editioned object.
Several issues with synonyms result from this. First, since the PUBLIC user is not a real schema and can’t be edition-enabled, all public synonyms for editioned objects are invalid and unusable. So you must drop them and replace them with private synonyms. That leads to the next issue. Those private synonyms resolve to objects in their edition (or the nearest parent edition they are instantiated into) when created. So far so good, all is normal. But now imagine creating a new edition that is a child of the current edition and compiling some objects there that use the synonyms in what is now the parent edition. If the synonym in the parent edition resolves to an object with a version in both editions, which one does the calling object get the dependency on? You would want, and expect, it to be the parent object in the edition that the dependent object belongs to, since that preserves our understood assumption that synonyms act like an alias. I have not found that to be consistently true. The synonyms seem to respect the object id rather than the name and can resolve to different edition-version of an object than you would get if you were using a fully qualified name instead of the synonym.
It took me a while to sort out that this was happening and figure out how to deal with it. My basic rule now it to never trust the inheritance of dependencies across editions. Perhaps it will be change to work correctly at some point, but in the mean time, this will cause you much grief if you simply follow Oracle’s examples. Here are my recommendations:
1) Use the fully qualified name of the object if feasible to avoid using synonyms at all
2) If you must use the private synonyms, compile them in each edition in which a version of the object they resolve to exists