LLBLGen 3.0; Entity Framework

We have a table with a blob field. We would like to create two entities from that table

EntityB - with the id and blob field EntityA - with id and rest of the fields

EntityA and EntityB has 1-1 relationship

This scenario is supported in the visual studio designer.

When we tried to do the same with LLBLGen designer, it is complaining that EntityB didn't map to required fields.

Are we missing something?

This should be supported ('split entity scenario'), could you describe the error (copy it to the clipboard using the copy button) or attach the llblgenproj so we can look into it? thanks.

I reproduced this with Northwind Employees table

Message type: Error

Message text: The entity 'EmployeeImage' is mapped onto table 'NORTHWND.MDF.dbo.Employees', however the non-nullable field(s) 'FirstName, LastName' are not mapped by any field in 'EmployeeImage'. The Entity Framework requires a valid entity field to be mapped onto these fields.

Source: Project Validation Created on: Monday, August 16, 2010 7:25 PM

Corrections/suggestions Choice 1: Open the entity 'EmployeeImage' in its editor and on the 'Field Mappings' tab, use the reverse engineer button to create entity fields mapped onto the unmapped target fields. Make sure the names don't clash with inherited fields (if applicable).

I also noticed that default EF designer allows you to move 'not null' fields to EntityB, where as LLBLGen designer is not allowing me to do the same.

Hi chad,

chand wrote:

Corrections/suggestions Choice 1: Open the entity 'EmployeeImage' in its editor and on the 'Field Mappings' tab, use the reverse engineer button to create entity fields mapped onto the unmapped target fields. Make sure the names don't clash with inherited fields (if applicable).

Did you try the suggestion?

chand wrote:

I also noticed that default EF designer allows you to move 'not null' fields to EntityB, where as LLBLGen designer is not allowing me to do the same.

Could you please elaborate more? What do you mean by "move 'not null' fields to EntityB"?

chand wrote:

I reproduced this with Northwind Employees table

Message type: Error

Message text: The entity 'EmployeeImage' is mapped onto table 'NORTHWND.MDF.dbo.Employees', however the non-nullable field(s) 'FirstName, LastName' are not mapped by any field in 'EmployeeImage'. The Entity Framework requires a valid entity field to be mapped onto these fields.

Source: Project Validation Created on: Monday, August 16, 2010 7:25 PM

Corrections/suggestions Choice 1: Open the entity 'EmployeeImage' in its editor and on the 'Field Mappings' tab, use the reverse engineer button to create entity fields mapped onto the unmapped target fields. Make sure the names don't clash with inherited fields (if applicable).

Hmm. it indeeds allows it, if the entity is a 'split-off entity'. This is a bug, we'll fix it in the next build.

I also noticed that default EF designer allows you to move 'not null' fields to EntityB, where as LLBLGen designer is not allowing me to do the same.

I don't see how you can move fields in the EF designer, but you can reverse engineer fields from a target field, in the field mappings tab in llblgen pro.

1. I am attaching .llblgenproj file to help you see the model.

2. I am attaching couple of screen shots how the non nullable fields are allowed to be split in VS EF designer.

Here HighResolutionBits property is notnull in db. I was able to split in to a different entity. And here are the steps I followed.

Create New Entity Create ProtoId Property Move HighResolutionBits property to new entity Create 1-1 association with a referential constraint between the two entities

Previous post allowed be to add only one attachment. Here is the VS studio attachment.

All the fields in Phtoto entity are not nullable.

I can repro it on northwind, that's also why I said: we'll look into it.

What I don't see is 'move property to entity', in EF designer. I dragged/dropped, checked menus but there's no such thing. Anyway, go to fieldmappings tab, click the reverse engineer unmapped fields button to get the field, without manual labor.

Please use the attached EF validator dll to fix the validation problem you had with the split-entities.

(works for v1 and v4, v4's validator builds on top of v1's )

copy the file as administrator in the folder: <llblgen pro installation folder>\Frameworks\Entity Framework

Thanks for quick turn around Frans!

What I don't see is 'move property to entity', in EF designer. I dragged/dropped, checked menus but there's no such thing.

When I said move, I meant cut the property in Photo Entity and Paste it in to the PhotoImage entity.

Anyway, go to fieldmappings tab, click the reverse engineer unmapped fields button to get the field, without manual labor. Wink

It looks like I didn't explain the problem correctly.

In a split-off entity scenario LLBLGen designer expects that the split off entity should have only optional fields.

I am not able to resolve the following errors in the designer.

First I get the following error

Message type: Error Message text: For the database with driver 'SQL Server 2000/2005/2008/Express Driver (SqlClient)', the field 'HighResolutionBits' in entity 'PhotoImage' isn't marked as optional, while its containing entity is a split-off entity of entity 'Photograph' which doesn't have this field mapped. Source: PhotoImage Created on: Tuesday, August 17, 2010 12:26 PM Corrections/suggestions Choice 1: Open entity 'PhotoImage' in its editor and manually mark the field as Optional or otherwise correct the error. ** If I make the HighResolutionBits optional in PhotoImage entity, as suggested (just to see what happens) I get the following error**

Message type: Error Message text: The mapping of sub-element 'HighResolutionBits' of entity 'PhotoImage' for the target database with the driver 'SQL Server 2000/2005/2008/Express Driver (SqlClient)' has the following errors: - MappedTarget: The IsNullable flag on target field 'Photograph.HighResolutionBits' is set to 'False' while the IsOptional flag of the mapped field 'HighResolutionBits' is set to 'True' Source: PhotoImage mapping Created on: Tuesday, August 17, 2010 12:22 PM Corrections/suggestions Choice 1: Open containing element 'PhotoImage' in its editor and manually correct the errors.

The idea behind split entities is that the split-off part has nullable fields, so when you save the root (main) entity, the fields which are in the split-off part are not saved so they have to be nullable.

Otherwise how are you going to save the main entity? it has to save null in the blob field which is in the split-off entity. The root (main) entity is saved first as an insert, then the split-off part is saved but as an Update on the same row. the insert will fail if a table field which isn't nullable is in the split off part but not in the main part.

To mark the target field nullable, go to the field mappings, select the field + mapping row, then click 'Edit field' at the right bottom corner and in the dialog check the checkbox. This will require you to export DDL SQL of course to mark the field in the DB as nullable.

If I have misunderstood it, please correct me

Yes you are right about the inserts and updates.

What if it is acceptable to have a restriction that both the entities are required for save operation and I would like to optimize just the reads?

I could set the LazyLoading to false and any attempt to retrieve the main entity would not load the expensive image column in the split-off entity.

VS designer allows me to do this. If you like to see I can send you the sample.

chand wrote:

Yes you are right about the inserts and updates.

What if it is acceptable to have a restriction that both the entities are required for save operation and I would like to optimize just the reads?

I don't really see the point of this, as both entities are separately saved: first the root (main) entity, with an insert, then the split off entity with an update on the same row. This is what the EF does, to my knowledge (and also how we do it in our own framework).

It would have been better if they had implemented something like we have in our own framework where you can simply exclude fields in your queries, and fetch them later on in a batch.

Anyway, sadly we don't control what restrictions the EF forces upon its users. The validation we built in is to make sure the edmx and code work at runtime. So we don't control whether it's possible to merge the entities in-memory to 1 insert statement. If we could, we'd have done that .

I could set the LazyLoading to false and any attempt to retrieve the main entity would not load the expensive image column in the split-off entity. VS designer allows me to do this. If you like to see I can send you the sample.

Lazy loading on the context is enabled/disabled though the settings in the output settings values tab in project properties. The split-off entity is never loaded when you load the main entity btw. If you enable lazy loading it is loaded when you actively access the navigator on the main entity to retrieve the split-off entity, if you don't enable lazy loading, it's simply not there.

The validation we built in is to make sure the edmx and code work at runtime.

The validation in LLBLGen designer is preventing me to split off an entity with a not nullable field, where as VS designer allows this scenario and creates valid edmx file that doesn't fail at run time.

I am attaching the edmx file generated by VS designer.

chand wrote:

The validation we built in is to make sure the edmx and code work at runtime.

The validation in LLBLGen designer is preventing me to split off an entity with a not nullable field, where as VS designer allows this scenario and creates valid edmx file that doesn't fail at run time.

Doesn't fail, as in: it is able to insert a row in the main entity and later on a row in the split-off entity? mind you: the split-off entity is 'optional', so inserting a new row in 'photo' has no idea how to save data in HighResolutionBits, as there's no field mapped onto it.

I am attaching the edmx file generated by VS designer.

I'll try to save a row in such a table, but I fail to see how that's ever going to work...

btw, your project has the PhotoImage as the main entity as that's the one with an identity pk.

(edit) whoopps... EF designer creates 2 tables from your model. Hand-coding the db for testing...

When I use your model, 1 table, and I only create a PhotoImage (as that's the identity field holding entity) and save it, I get an exception that a required relationship is missing. Also when I save the Photo, I get the same exception.

Apparently, EF's entity splitting is not for persistence, only for fetches. Gee, where did they document that...

So indeed, they seem to merge it into 1 insert statement, but the optional data is required, so it's not really a split-off entity: it's not optional (regardless whether it's optional for fetching, if it's not optional for saving, you have to create the optional entity and store data in it and persist it as well).

I can understand you don't want to have this field as 'optional' because it is a 'required' field for the whole entity, you however want to have the fetching capabilities of the split-off entity.

We'll move the check to the base class of the validators, so frameworks which require this can call the method to validate on this, and out of the main validation cycle, so only frameworks which require this are testing for this (EF validator will not test for this). That should solve your problem.

Ok, fixed in next build. Validation has been moved out the main engine and into the project specific validator (base). EF is now validating differently on this than our own framework. EF will still make sure all non-optional fields are mapped in a split-off scenario, so extra logic for that is added.

In next build, 18th of August, which will be available in an hour.

Thank you Frans!

It's available now. Hopefully you can now proceed with splitting the stuff up without errors