We've been using CSLA 4.5.600 for years, for some reasons migration to every more newest version was postponed.
Now, we'd like migrate to latest one (5.3.1)
mostly it was OK, we've got compilation errors (interfaces as incmoing parameters instead of objects etc) but we were ready for this. Eventually we fixed all compile-time errors. Ran test, most of them were OK.
But we are not ready to faced with problems with "child" objects.
Seems, there are some changes deeply inside of CSLA core, that produced hard to find bugs.
Seems, it goes for properties IsNew, IsDirty, IsSavable etc
Example:
we have some class, let's name it Parent
we've have some Child class that is a property on this Parent object.
we have tables Table1 and Table2
we create an object Parent1 it must be stored in the Table1 and his Child Property will be stored in the Table2 (parentid) must target parent1'id in the Table1
we create an object Parent2 it must be stored in the Table1 and his Child Property (parentid) must target parent2'id in the Table1.
In the CSLA 4.5.600 we did something like that:
Csla.Data.DataMapper.Map(parent1, parent2, true);
Csla.Data.DataMapper.Map(parent1.Child, parent2.Child, true);
and Child property on parent2 has:
IsNew = true
IsDirty = true
IsSavable = true
but if we're using CSLA 5.3.1 this code provides us:
IsNew = FALSE (!!!!)
IsDirty = true
IsSavable = true
so, instead of creating a new record in the Table2 for parent's2 child, it updates a record for Child's property of the parent1's object!
so, workaround for CSLA 5.3.1 is:
string[] ignoreList = new string[] {"Child", "IsNew", "IsDirty" };
Csla.Data.DataMapper.Map(parent1, parent2, true, ignoreList );
Csla.Data.DataMapper.Map(parent1.Child, parent2.Child, true, ignoreList );
but, wel, we have hundreds of classes. Our project heavily based on CSLA. Of course, it was very big mistake not to update to every latest CSLA release, even we had some reason to stay on old version, but, well, now is October 2020 and we need somehow to understand when this breaking changes were introduced, how they are affecting not only mapping but something else also?
Problem not just to find workaround for this mapping,
Idea is to understand how this changes somewhere inside of deep internals of CSLA affects all CSLA functionality, which also is "broken" but we have no idea that is broken because of no compilation errors and we have about 60% tests coverage of existing codebase/functionality, but 40% still has no tests, so
We bought all CSLA books already few years ago, but they are targeting CSLA 4, so, they couldn't help us with CSLA 5 breaking behavior.
Reading github "release notes" didn't help much. Is there a blog post, or youtube videos or something else that could explain questions above?
It is possible that this is a bug in #cslanet - though the tests for CSLA itself haven't changed and continue to pass.
Can you provide a simple repro of the issue and file it as an issue in the repo?
https://github.com/MarimerLLC/csla/issues
(it sounds like the bug might be in DataMapper, which did get some updates, and so it is possible a bug was introduced there)