Why does LightSpeed try to insert child objects before their parent?

I have a DataSource class, which has many Events. Events may also be used as a super class. Currently I have one subclass, which uses concrete table inheritance.

I'm parsing text files, each of which creates one DataSource and many Events. I then add all these entities to my UnitOfWork and attempt to save. This was working great until something changed and now my Events are INSERTed before my DataSource, causing a foreign key constraint to fail. I am using the trace logger and can see that Lightspeed claims to be inserting them all in a single query. That single query previously inserted the DataSource first, but now insists on inserting it last.

I am only making one call to SaveChanges and all entities involved use LightSpeed's key table. I am using MySQL 5.5 and the latest release of LightSpeed.

How can I fix this, and what did I do to make LightSpeed suddenly decide to go about it this way?

Here is the query LightSpeed claims is returning the error:

INSERT INTO EventTable
(
  Id, SourceId, ...
)
VALUES
(
  6, 7, ...
);

INSERT INTO EventSubclassTable
(
  Id, ...
)
VALUES
(
  6, ...
);

INSERT INTO DataSource
(
  Id, ...
)
VALUES
(
  7, ...
)

This shouldnt be happening. Check if using the EnableCandidateFixes option described in this thread: http://www.mindscapehq.com/forums/thread/350704 covers the issue for you as it sounds like it may well be the same issue. If not could you please send through a small repro project for this and I can have a look into this.

Thanks!
Jeremy

Thank you, this appears to be working.

For the record, EnableCandidateFixes is terribly documented.. It doesn't appear anywhere in the .pdf, and only occurs in this and the referenced thread in the forum. I had to download kiwidev's repro to figure out it was an option under LightSpeedContext.CompatibilityOptions. Is there any documentation I'm missing where I can go to find things like this?

Its deliberately obscure - that flag is only there to enable specific changes that are in the nightly builds but would break existing behavior. This will ultimately become a proper documented option (under a different name) later on.

Jeremy