LLBLGen Pro Support System LLBLGen Pro Runtime Framework feed

Insert ordering regression after upgrade from LLBLGen 5.1.0 to 5.11.1 by Otis

Otis — Thu, 21 May 2026 06:23:08 GMT

First, please next time don't generate a wall of text with some AI tool, write it out manually. thanks.

In 5.5.2 we made a bugfix, which is described by this post: https://www.llblgen.com/tinyforum/Message/Goto/144684

Before that fix, it was undefined what the order was, basically the order in which the entities were stored in the unit of work. We don't utilize relationships for figuring out the order. To make the runtime figure out what the order is, it's best to define the relationships through the navigators, as the topological sort algorithm of the graph will then find them. This indeed requires to specify true for recursing the graph. This is very fast and doesn't mean all entities in the graph are added for the save operation; only the ones which have been changed or are new are added (as you wanted to save them anyway!).

Insert ordering regression after upgrade from LLBLGen 5.1.0 to 5.11.1 by Ashutosh

Ashutosh — Wed, 20 May 2026 18:04:22 GMT

Hello LLBLGen Support Team,

We are currently upgrading our application from LLBLGen Pro 5.1.0 to 5.11.1 and are encountering a change in UnitOfWork insert ordering behavior which appears to affect parent-child entity persistence. We would appreciate clarification on whether our understanding is correct and whether our proposed fix aligns with the intended 5.11 behavior.

Problem Summary: After upgrading from 5.1.0 to 5.11.1, inserts that previously succeeded now fail with FK violations because child entities are inserted before parent entities.

Example: WorkflowDraftStatus references WorkflowDraftSchema Both are new entities in the same UnitOfWork In 5.1.0 the parent was inserted first automatically In 5.11.1 the child may be inserted first unless navigation properties are explicitly wired

Our current understanding is that this is due to a change in how insert dependency ordering is determined.

Observed Behavioral Difference:

In 5.1.x: Insert ordering appeared to be driven primarily by static FK metadata / entity type relationships Even when only scalar FK fields were assigned, inserts were ordered correctly

In 5.11.x:

Insert ordering appears to rely on instance-level relationship graphs Dependency edges are discovered through related entity navigation wiring Scalar FK assignment alone no longer seems sufficient

Specifically, we observed that ordering now depends on:

IEntityCore.GetDependentRelatedEntityCoreInstances() _relatedEntitiesToCommit being populated Navigation setters such as SetSingleRelatedEntityNavigator / SetRelatedEntity being invoked

In our BusinessObject layer, many relationships historically only set scalar FK values and do not always invoke generated navigation setters.

Question 1

Is it correct that: 5.1.x used a more metadata/FK-driven insert pre-sort 5.11.x now depends primarily on per-instance navigation dependency graphs?

Question 2

We found that explicitly wiring navigation properties via reflection on the IEntity2 instance resolves ordering issues in many cases:

PropertyInfo.SetValue(childEntity, parentEntity);

Our understanding is that this still correctly invokes the generated entity setter and therefore:

populates _relatedEntitiesToCommit invokes SetSingleRelatedEntityNavigator participates in dependency graph construction

Can you confirm this is a supported and valid approach?

Question 3

We also tested changing:

uow.AddForSave(entity);

to:

uow.AddForSave(entity, null, true, true);

Specifically enabling:

recurseSavedAndDeletedEntities = true

This appears to resolve ordering issues consistently.

Our understanding is that recursion:

walks GetAllRelatedEntities() registers additional dependency edges inside the UnitOfWork enables proper topological ordering even if scalar FK assignment bypassed relationship tracking earlier

Is this the intended mechanism in 5.11.x for ensuring graph dependency ordering?

Question 4

Would you recommend:

explicitly wiring navigation properties everywhere, OR enabling recurseSavedAndDeletedEntities=true for save operations involving complex object graphs?

We are hesitant to globally enable recursion because it expands save scope and may introduce unintended persistence behavior.

Current Thinking

Our current preferred approach is:

Keep explicit relationship wiring in the package installation path Use: uow.AddForSave(entity, null, true, true) only in the package install pipeline Avoid globally changing all BusinessContext save operations

Does this align with recommended LLBLGen usage patterns for 5.11.x?

Any clarification on the intended dependency-ordering behavior changes between 5.1 and 5.11 would be greatly appreciated.

Thank you.

Custom type converter and nullability in projection by Findev

Findev — Sun, 08 Mar 2026 10:35:22 GMT

Otis wrote:

That was a bit of complicated debugging as the problem wasn't showing till the lambda was executed which is impossible to step through, but checking what the runtime is building for the projection lambda revealed what the core of the issues is. The DTO projection will use a helper method for the ToValue<datetime?>, namely DataReaderProjectionRow.GetNullableDateTime(int i), which checks if the value obtained from the datareader is DBNull.Value and if so, return null. As your typeconverter converts DBNull.Value to null, this check fails and it returns a normal DateTime.

So to fix this, change line 24 of your type converter to return value and it works fine.

Like:
if (value == null || value == DBNull.Value)
{
    return value;
}

ah, the case of not all nulls are created equally and neither they are treated as such

Thank you!

Custom type converter and nullability in projection by Otis

Otis — Sun, 08 Mar 2026 09:28:58 GMT

That was a bit of complicated debugging as the problem wasn't showing till the lambda was executed which is impossible to step through, but checking what the runtime is building for the projection lambda revealed what the core of the issues is. The DTO projection will use a helper method for the ToValue<datetime?>, namely DataReaderProjectionRow.GetNullableDateTime(int i), which checks if the value obtained from the datareader is DBNull.Value and if so, return null. As your typeconverter converts DBNull.Value to null, this check fails and it returns a normal DateTime.

So to fix this, change line 24 of your type converter to return value and it works fine.

Like:

if (value == null || value == DBNull.Value)
{
    return value;
}

Custom type converter and nullability in projection by Otis

Otis — Sun, 08 Mar 2026 08:31:55 GMT

Thanks, we'll look into it!

Custom type converter and nullability in projection by Findev

Findev — Sat, 07 Mar 2026 10:51:28 GMT

Otis wrote:

The type converters are run right after the row has been received from the datareader (See FetchProjectionFromReader in ProjectionUtils.cs ). The value is therefore DBNull.Value in the row from the datareader. At least, it should be.

Please place a breakpoint on the if (value == null || value == DBNull.Value) line during the projection and see if that's indeed the case. Also, without more information, e.g. the C# query and the SQL query executed, it's hard to say what's wrong...

(e.g. are the converters run at all? )

was hoping would be able to dodge the repro here you go: https://drive.google.com/file/d/1H-5EtgA8z35qm1zlVWfv4GgxwkYLMiTI/view?usp=sharing

Custom type converter and nullability in projection by Otis

Otis — Sat, 07 Mar 2026 07:06:08 GMT

The type converters are run right after the row has been received from the datareader (See FetchProjectionFromReader in ProjectionUtils.cs ). The value is therefore DBNull.Value in the row from the datareader. At least, it should be.

Please place a breakpoint on the if (value == null || value == DBNull.Value) line during the projection and see if that's indeed the case. Also, without more information, e.g. the C# query and the SQL query executed, it's hard to say what's wrong...

(e.g. are the converters run at all? )

Missing ModelInfoProviderSingleton by Otis

Otis — Sat, 07 Mar 2026 06:53:57 GMT

https://www.llblgen.com/tinyforum/Thread/7722/1

Custom type converter and nullability in projection by Findev

Findev — Fri, 06 Mar 2026 21:11:49 GMT

Hi,

MSSQL, ORM 5.12.x. Table has a nullable column of type datetime2(0). I have a very old custom converter which basically validates that all DateTimes are UTC in both directions. Here is the slightly modernized version:

using System;
using System.Collections;
using System.ComponentModel;
using System.Globalization;

namespace SD.LLBLGen.Pro.TypeConverters;

public class SqlDateTimeToUtcDateTimeConverter : TypeConverter
{
    public override bool CanConvertFrom(ITypeDescriptorContext context, Type sourceType)
    {
        return IsDateTime(sourceType);
    }

    public override bool CanConvertTo(ITypeDescriptorContext context, Type destinationType)
    {
        return IsDateTime(destinationType);
    }

    public override object ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, object value)
    {
        if (value == null || value == DBNull.Value)
        {
            return null;
        }

        if (value is not DateTime dt)
        {
            throw new NotSupportedException(
                $"Conversion from a value of type '{value.GetType()}' to System.DateTime isn't supported"
            );
        }

        return DateTime.SpecifyKind(dt, DateTimeKind.Utc);
    }

    public override object ConvertTo(ITypeDescriptorContext context, CultureInfo culture, object value, Type destinationType)
    {
        if (destinationType == null)
        {
            throw new ArgumentNullException(nameof(destinationType));
        }

        if (!IsDateTime(destinationType))
        {
            throw new NotSupportedException($"Conversion to type '{destinationType}' isn't supported");
        }

        if (value == null)
        {
            return null;
        }

        if (value is not DateTime dt)
        {
            throw new ArgumentException("Value isn't of type DateTime", nameof(value));
        }

        if (dt.Kind != DateTimeKind.Utc)
        {
            throw new ArgumentException("Value must be DateTime UTC", nameof(value));
        }

        return dt;
    }

    public override object CreateInstance(ITypeDescriptorContext context, IDictionary propertyValues)
    {
        return DateTime.UtcNow;
    }

    private static bool IsDateTime(Type type) => type == typeof(DateTime);
}

while I didn't dig deeper and in isolation, but rather via existing test it seems that nullablity is not being respected in projection when field has converter assigned. I.e. if I fetch entities directly and that column is null in the database - corresponding entity property is null as well, however, when I fetch via projection:

DateLastValidated = XXXFields.DateLastValidated.ToValue<DateTime?>()

then instead of a null it seems to get a DateTime.MinValue. If in Designer for that field "TypeConverter to use" is set to "None" (removed) then projection correctly assigns null. Feels like type converter is somehow affecting this. For now (will be changed in the future) project settings have "Convert nulled reference types to default value" checked. But unchecking it doesn't seem to help anyway.

Thank you!

Missing ModelInfoProviderSingleton by B Rightmer

B Rightmer — Fri, 06 Mar 2026 15:23:24 GMT

Otis wrote:

cadsjo wrote:

Hi Otis,

I think I found it.

There are 2 new .csproj files generated. I am going to use those. And there is a ModelInfoProviderSingleton class..

You might have missed the important remark about the migration of the csproj files. https://www.llblgen.com/Documentation/5.10/LLBLGen%20Pro%20RTF/migratingcode.htm#migrating-generated-code-from-v5.3-to-v5.4

I have moved my files a couple different ways and only ever see one generated .vbproj file generated. And that project file doesn't have a references to ModelInfoProviderSingleton. Is that a file of reference I can add to existing project?