Open bartread opened 9 years ago
This is really weird. I've spent a bit of time trying to reproduce this, even going to the extent of copying the exact object definitions that fail in PS and duplicating them in the test case, and it fails, but for a different reason. Rather than in the script generation, which is where I'd expect it to break, it's failing (predictably) when it tries to execute the SQL because we don't have a real, open connection to a database.
I'm quite certain I know how to fix it but I don't want to go ahead and do that, ideally, without a test in place that demonstrates it's now fixed.
This appears to be fixed but it would still be nice to have a test that reproduces it and protects against regression.
In our case we've got types referencing eachother like this:
UserDto
>PhoneNumberDto
>CountryDto
>CurrencyCodeDto
.PhoneNumberDto
isn't reference data, but is treated as such because the relevant properties onUserDto
are marked as reference data, like so:CountryDto
andCurrencyCodeDto
are both reference data and marked as such at the type level with[ReferenceData]
attribute decorations.The problem occurs when you try to INSERT a
UserDto
. Now SimpleSave 1.0.65 correctly skips the PhoneNumberDto but, of course, it's continued to diff all the way down beyond that, so generates anUpdateOperation
, which gets caught later as invalid, and leads to the following error:It's good that the problem is caught and the error thrown, but the fact remains that operations for tables that are children of the initial reference data table should not be generated.
This actually needs to be fixed at the diff level, before we start generating operations because, by that point, the hierarchy information isn't available in an easy to digest form.