Hey guys,

Our application use LLBLGen 3.1 and now I'm trying to migrate to 5.1. We did some changes to the templates of 3.1 as well as changed implementation (read provided our own implementation) of some core classes as an example FieldInfoProvider. So it looks like it is not possible to have my own implementation of FieldInfoProvider in 5.1. Why? The reason for it is in the class StaticEntityFieldsDataContainer which has an internal constructor so I'm not able to create it. The instance of this class has to be passed into the constructor of EntityFields2, otherwise it just doesn't work properly in case when Entity is used.

Am I missing something? Is there anyway around it? Can you guys help me with it?

Thanks, Anton

why would you need your own implementation of the fieldinfoprovider? It provides field info objects which are static and shared among entity instances, I have no idea why one would change that. Could you give a use case?

Otis wrote:

why would you need your own implementation of the fieldinfoprovider? It provides field info objects which are static and shared among entity instances, I have no idea why one would change that. Could you give a use case?

Well, we provide our own implementation to store fields information differently i.e. in the database so that we can easily change it later on. Essentially we implemented a functionality to add new fields to entities at run-time.

Anton

The change in architecture was to share objects which are immutable among all fields, to increase performance. Adjusting them at runtime means they're adjusted for all instances of the same type. However there are other problems too: we store field values in an array inside the entity. Adjusting the fieldinfo array for an entity also requires adjustment of that array.

The main setup is that when an entity is instantiated, it obtains an entityfields(2) object which gets two containers: a VolatileEntityFieldsDataContainer and a StaticEntityFieldsDataContainer. One for the data that changes (field data) and one for the static data which doesn't change (field info).

We store the fetched data in one go in an object[] array inside the VolatileEntityFieldsDataContainer during fetches.

Adjusting a type at runtime after everything has already started is therefore a bit difficult: the VolatileEntityFieldsDataContainer and StaticEntityFieldsDataContainer both have to be adjusted to match the new type.

Well, completely agree with you that people who provide their own implementation of core interfaces, classes of the framework should be very careful about it, and understand what they do and why, and what is the contract between the framework and user's code. Definitely all the errors related to such changes are not responsibility of the LLBLGen Framework developers, if that contract is broken.

So now understanding all the consequences of the changes, I wanted to provide my own implementation of the interface (similar to v3.x), and I can do that, but my code doesn't work as expected. We found it right away that we use a wrong constructor for EntityField2, and we have to use the one that accepts StaticEntityFieldsDataContainer. It makes sense till this point, but once we figured that the constructor StaticEntityFieldsDataContainer is internal - now it doesn't make sense.

As for me, looking into the overall design, and architecture of LLBLGen, where everything was open, configurable, and you can plug your custom stuff (types, predicates, authorization, etc.) easily, it was a bit surprising to see this limiting constraint. I can not really find a reason as per why do you want to keep constructor of that class internal.

So as for me it looks like a minor mistake that can easily be fixed without a lot of impact and re-verification.

Do you think you can make the change?

P.S. We do have a workaround for it - use reflection, but I'd rather do not go this way.

Thanks, Anton

The ctor isn't made internal for a specific reason other than in general one shouldn't use it themselves. I agree it's restrictive if you want to create an instance for yourself for that reason. We'll make the ctor public in the next 5.1.1 hotfix build. Any other ctors that need to be public for this particular scenario? Or methods of this class that need to be public? E.g. Expand is internal too, but could be useful to you.

Ok sounds good. As for now we have just started migration to 5.1, and still in process of fixing some of our classes. It was the only block that we hit till this moment. We hope to finish it in 2-4 days and move on.

Thank you so much for your help and a very good framework that we enjoy using for years.

Anton

In the next v5.0/v5.1 release (5.0.9 and 5.1.1) the members of StaticEntityFieldDataContainer are public instead of Internal. These releases will be available later today