Bryan & Michael,
It sounds to me like the scenario that you are describing has to do with
committing multiple entities and that the *order* can be re-set from what was
intended.
Since I have no idea what the problem is, I am open to suggestions. However, I
checked the code, and it appears that there is only one entity being committed.
The Product entity has a "toOne" relationship with PackageType. The
PackageType table is populated once for the life of the app. When I build a
new Product entity, I first obtain a default PackageType with a custom static
method:
PackageType packageType = PackageType.fetchPackageTypeList().get(0);
Then I set the Product PackageType
entity.setPackageType(packageType); // default: smallest package
Then, after initializing the rest of the Product entity, I commit changes
BaseContext.getThreadObjectContext().commitChanges();
Essentially, I am getting an entity from MySQL via Cayenne, supplying that
entity to the second entity and then committing the creation of the the second
entity. This is like Cayenne-elementary-school.
I have been coding Cayenne power apps for over a year with this method. In
fact, I have an app, (that I duplicated) currently running on the same webhost,
using the same custom Cayenne powered code I created, that has never once
failed due to this error.
I have verified the libs about 5x. Checked my code about 10x. Checked the
pool manager configuration about 3x. I rebuilt the app and stress tested it
100% successfully on my dev server. It continues to fail 100% of the time on
the production server.
If the "MySQLIntegrityConstraintViolationException" is indicative of anything,
I have *absolutely* no idea how to gain any more visibility into the problem.
(So I simply put println statements in the code so I could log that it was
actually returning the PackageType entity, and of course, it was returning the
correct object completely populated. The Exception cannot be verified as being
correct given the empirical data.)
I am going to be *really* upset if this turns out to be the WebHost dudes
forgot to flip some switch on my account (which, btw, has happened before). :)
Joe
On Feb 7, 2012, at 11:48 AM, Michael Gentry wrote:
> Hi Bryan,
>
> I can confirm that the commit order varies. We were seeing the issue
> on the same environment, though. When the AshwoodEntitySorter built
> the object graph, it would vary from run-to-run. Once built, it is
> cached. If it happens to build a proper order, you are good to go at
> least until you restart. For our particular issue, we had a deep
> object graph cycle that didn't throw any exceptions. The
> AshwoodEntitySorter doesn't work so well with cycles. Once we removed
> that relationship, the problem went away.
>
> mrg
>
>
> On Mon, Feb 6, 2012 at 7:18 AM, Bryan Lewis <[email protected]> wrote:
>> This error reminds me of something we see in our shop. If multiple related
>> entities are being committed together, Cayenne can sometimes commit them
>> out of order which can cause FK constraint violations. The commit order
>> seems to be indeterminate; it can work as expected on a dev machine and
>> fail in production.
>>
>> Look at the SQL issued just before the error. On one server you might see
>> the packagetype being inserted before the product, but the other way around
>> on the other server. If this is the problem, the fix is to subclass the
>> AshwoodEntitySorter as has been discussed a couple of times in the list.
>>
>>
>>
>> On Sun, Feb 5, 2012 at 6:48 PM, Joe Baldwin <[email protected]> wrote:
>>
>>>
>>> Here is the current error (which is really odd because it is working just
>>> fine on my dev server)
>>>
>>> com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException:
>>> Cannot add or update a child row: a foreign key constraint fails
>>> (`eagle1_om28`.`product`, CONSTRAINT `product_ibfk_2` FOREIGN KEY
>>> (`packageTypeOid`) REFERENCES `packagetype` (`oid`))
>>>
