We have some legacy code using LLBLGenPro 3.5. Long time ago we introduced custom fields collection :

public class CustomEntityFields : EntityFields2, IEntityFields2

It also uses own type of fields:

public class CustomEntityField : EntityField2

I have tried to migrate that code to newest version of LLBLGenPro, sadly I ran into issues with these types (maybe there are more, but at the moment the place where I am blocked).

Problem for me is that LLBLGen framework expects that fields collection used in entity is created using constructor which accepts StaticEntityFieldsDataContainer staticData, which then sets this._inEntityDataMode = true; There is no other way to set this mode.

By default standard fields collection is created inside FieldInfoProvider which is internal and cannot be accessed by user code. I have tried to copy that code in order to set my own IFieldInfoProvider .. But its implementation uses other internal methods of FieldInfo like for example SetIsInMultiTargetEntity.. and so on and so on..

Currently with existing 5.x LLBLGen implementation we are not able to migrate our legacy code to newer version because of these issues. One of possibilities of course would be to get rid of those custom collections, but it is so deep in the code that it would be easier to rewrite everything (and then would arise question of ORM... ).

So my question then would be: do you have any suggestions how to solve that?

Internally the EntityFields2 collection uses 2 arrays, one for the static, shared field information and one for the values. We did that to get rid of the high allocation and CPU pressure when creating entities, as before every field value was wrapped inside an EntityField2 object. We use arrays as we don't support entities with flexible field amounts.

The inEntityDataMode flag is to signal values are in the arrays, if it's false, values are assumed to be in the entityfield objects and e.g. field index dictionaries are created.

To support the existing API where we did support expanding the EntityFields2 object, we can expand them to newer sizes. In the EntityFieldsCore.this[int] property code you'll see how it works internally.

This is a complicated mechanism and was built mainly to heavily optimize an entity's instance memory and cpu footprint through the pipeline. For instance fetching an entity row is now as simple as copying the whole array of values into the volatile array and that's basically it. With entity fields, they have to be set per field object, which is much slower.

I don't know what you added to the CustomEntityFields class, but if it's code to support flexible entity field amounts at runtime, then it'll be complicated.

Otis wrote:

I don't know what you added to the CustomEntityFields class, but if it's code to support flexible entity field amounts at runtime, then it'll be complicated.

Thanks for explanation. I would be glad to remove this custom collection as well... for me it would be also fine if this class is empty just derived from EntityFields2.. but I cannot achieve this using regular (non reflection) methods.

Some overrides are related to old versions which was not supporting multiple levels of "Undo" in windows forms applications. I am sure, I can get rid of those. But still my issue - that these custom collections and types are used everywhere in our code..

LLBLGen is very flexible and adaptable in many scenarios - but this flexibility and possibility to change/override templates also comes with some wrong choices which are hard to migrate to newer versions.