Previous to a recent update, when an entity is saved (directly, or through a unit of work), the IsDirty flag on the entity was reset to “false”, even if that entity did not have any fields that were changed. This appears to no longer be the case. Is this intentional or an error. If intentional, is there a way to revert the behavior? Thanks Dan

please provide more info: https://www.llblgen.com/tinyforum/Thread/7722/1 E.g. a code snippet, version numbers would help

Certainly

// Fetch the asset and its artists
AssetEntity assetEntity = new AssetEntity((long)1);
IPrefetchPath2 assetPrefetch = new PrefetchPath2(EntityType.AssetEntity);
assetPrefetch.Add(AssetEntity.PrefetchPathAssetToArtistCollection).SubPath.Add(AssetToArtistEntity.PrefetchPathArtist);
assetEntity.DbRead(assetPrefetch, true);

// Get the first artist via the asset to artist collection
var firstAssetToArtist = assetEntity.AssetToArtistCollection.FirstOrDefault();
if (firstAssetToArtist != null)
{
    var firstArtist = firstAssetToArtist.Artist;
    if (firstArtist != null)
    {
        // Dirty the artist's name field
        firstArtist.Name = firstArtist.Name + "X";

        // Output the current state
        System.Diagnostics.Debug.WriteLine($"1) assetEntity.IsDirty: {assetEntity.IsDirty}, firstArtist.IsDirty: {firstArtist.IsDirty}");

        // Set the Asset's IsDirty to true, this is because we tie the enabled state of the 
        // save button to the entitie's IsDirty flag.  Even though the Asset is not dirty, one
        // of its related entities is
        assetEntity.IsDirty = true;

        // Output the current state
        System.Diagnostics.Debug.WriteLine($"2) assetEntity.IsDirty: {assetEntity.IsDirty}, firstArtist.IsDirty: {firstArtist.IsDirty}");

        // Create new General Database Adapter
        using (BengalDataAccessAdapter adapter = new BengalDataAccessAdapter())
        {
            // Do a recursive save on the Asset, it will save the Artist with the updated name
            adapter.SaveEntity(assetEntity, true, true);

            // Output the current state
            System.Diagnostics.Debug.WriteLine($"3) assetEntity.IsDirty: {assetEntity.IsDirty}, firstArtist.IsDirty: {firstArtist.IsDirty}");
        }
    }
}

Output when running with LLBLGen version 5.6.0.0

1) assetEntity.IsDirty: False, firstArtist.IsDirty: True

2) assetEntity.IsDirty: True, firstArtist.IsDirty: True

3) assetEntity.IsDirty: False, firstArtist.IsDirty: False << Note, after save, assetEntity.IsDirty was set to False by the framework

Output when running withLLBLGen version 5.10.0.0

1) assetEntity.IsDirty: False, firstArtist.IsDirty: True

2) assetEntity.IsDirty: True, firstArtist.IsDirty: True

3) assetEntity.IsDirty: True, firstArtist.IsDirty: False << Note, after save, assetEntity.IsDirty is still set to True

This is by design. It's a result of the introduction of the batch system and additionally some tweaks on that. So basically a result of the optimizations on the batch system. The main reason this is happening is that the AssetEntity you marked as dirty isn't going to end up being executed as a query. The query producer will produce an empty query for it (as no fields are dirty) and therefore it's skipped for processing and the post-persistence logic isn't run for this entity because of that.

This has as effect that everything is left as-is as nothing has been done with the entity. This isn't going to change.

For your scenario, it might be good to look into the Datascopes feature we have in the runtime. The datascopes are designed for a situation like this: they keep track of entities in the 'scope' and signal you if one or more are 'dirty' and you can anticipate on that by e.g. showing a button to save them. https://www.llblgen.com/Documentation/5.10/LLBLGen%20Pro%20RTF/Using%20the%20generated%20code/gencode_datascopes.htm See also the example: https://github.com/SolutionsDesign/LLBLGenProExamples_5.x/tree/master/Example_DataScope. The example might need retargeting of runtime libraries and code generation. It shows (among other things) a save button that's enabled based on an entity in the scope being marked as dirty because it has changed.

Thanks for the reply. I mainly wanted to confirm that this was an expected change. We will modify our code to accommodate this new behavior.