Problem Statement: Seemingly misleading FK exception from MySQL on production
server
Repeatability: 100% on the production server, 0% on the dev server
Status: It appears the theory of multiple universes could be part of the
solution set :)
****** New Test:
1. After setting Cayenne logging to DEBUG (in the last test) => the FK error
disappeared mysteriously (leaving me nonplused)
2. So I resorted to hacking.
3. Since I had initially duplicated the Database via a MySQL dump, I decided to
do it a different way.
a. I saved the Cayenne generated DB struct to a sql file and ran it.
b. I saved the Database data to a separate sql file an ran it.
c. I deleted all the cache files (that I could find)
d. I commented out the Cayenne logging directive
d. I restarted tomcat
4. Results: The FK problem has not occurred after 5 tests.
Does anyone have a clue as to what happened here, or should I just pour myself
a beer a call it "done". :) My current (unsubstantiated) theory is the the
Cayenne logging directive somehow "cleared the drains", but I am unsatisfied
with this "work boot" theory.
Thanks for all the patient comments.
Joe
On Feb 8, 2012, at 12:14 PM, Durchholz, Joachim wrote:
>> One thing you can do is to insert the P6Spy database driver into your app
>> -- this jdbc driver wrapper will provide logging at the jdbc level, which
>> would let you see what's going on without having to enable java logging.
>
> To see what part of the application is issuing the request, you could take
> the sources (available from
> http://p6spy.svn.sourceforge.net/viewvc/p6spy/trunk/src/main/java ) and
> insert logging of stack traces. That should at least point you in the
> direction what's responsible.
>
> There's actually (commented-out) code for that in
> com/p6spy/engine/common/P6LogQuery.java.
> Maybe do that only if the statement is the one that shouldn't happen so you
> don't get huge logs.
>
> HTH
> Jo
