cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Baldwin <>
Subject Re: Odd error
Date Tue, 07 Feb 2012 17:23:29 GMT
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

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). :)


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 <> 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 <> 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`))

View raw message