Both L and D in SOLID encourage us to program against contracts, not actual implementations. But does that mean an interface consumer should not know the implementation, or just that he should not rely on implementation doing something not stated in a contract explicitly?
I mean, we can have a method to create a new NumericParameter in DB, but its interface only says that! It does not say that NumericParameter is actually an inherited entity spanning over 2 tables, or that the method also creates one more related entity to save some more data about the created entity. Those are implementation details.
It's very clear why one should not depend on implementation doing something. But maybe it's justifiable to depend on implementation NOT doing something (even if it's not stated in a contract?) Otherwise, how are you going to modify your code at all? Any time you add some activity, it can come to conflict with something that is happening in some of the other methods and services you call. Like, you read a DB row "for update", then call foo() and then write a row back with some modifications, but it appears that foo() already made some changes to the same row - in this very transaction - and they will be overwritten.
On the other hand, implementation can be changed. If some consumer depends on it NOT doing something, then at some moment that dependency may break. Meaning, not only have we to examine what code is called from the code being edited, but also possible callers of the code. Everything that may be happening in any transaction triggering this code, we must know in details.
Somehow I think that is a smell, but how do you live without it? I usually try to ignore implementation details, but on multiple occasions that ended up in some conflicts.
All right, let me summarise the gathered wisdom.
1) Usually all significant effects of a method are either part of its contract (or should be), or are dictated by the environment (like it's with JPA's deletion having interference with JPA's modification some other entity). If it's the former, then the contract tell us what to expect, and if it's the latter, the developer is supposed to know the effect of environment he himself defined. So, in both cases he should be aware of possible conflicts without knowing implementation. A properly designed method can hardly cause some major effect totally unrelated to its contract and to environment/settings/etc., or at least no example of that comes to my mind or was mentioned by anyone else here. Unless, of course, that method is used by someone who knows it far too intimately and depends on its implementation; but in this case I of course have to know the implementation anyway and my question is not applicable.
2) In my question I mentioned implementation details like "inherited entity spanning over several tables" and "creates one more entity". Well, problems specific for JPA inheritance are part of environment; creating extra entities should either be part of contract (if the entity is referred by someone else) or not cause any interference (if it's strictly private thing), or be part of environment if it's product of some "aspect" introduced by configuration on top original method's logic.
Thus, the answer to my original question is "no need to know implementation details" (unless you have to work with tightly coupled classes), and "given properly defined contracts and properly designed methods, you can live without that because you should know everything you need from contracts and environment".