Hello,

I'm working with LLBLGen v3.1 final, released on February 23rd, 2011.

I have a view at my MsSQL 2008 server database, with in it multiple tables joined (Person, Address, Customer).

I have defined this view to be reverse-engineered as a typed view.

However, when I generate my source code (Fluent NHibernate), the wrong field gets chosen for being the ID field of the TypedView object! Instead my AddressHouseNumber field is defined as ID field, resulting in duplicate records in the resultset and thus duplicate records on my view in the application (WPF).

How can I tell LLBLGen that the PersonId field is the ID field? I already tried to change the fieldorder and set PersonId at the top (position 0), but in the code generation, AddressHouseNumber still gets chosen as ID field.

Thanks for helping me out!

Could you elaborate a bit why it results in duplicates? the data is readonly. Does nhibernate report duplicates?

The field ordering isn't used in nhibernate templates, it just picks the first field. If this results into problems, we'll change it, of course. (the line of code where the field is chosen in the template is 27, in typedViewFluentMapping.lpt)

With duplicate I mean that in WPF, in a listview, the collection of Employee given back by NHibernate contains the same Employee records because of the wrong ID field in the code generation (AddressHouseNumber is the same for some employees, these records are all considered the same employee, so if three employees live on housenumber 2, in the collection these 3 employee objects are all filled with the details of the first employee).

So for typed views there should be an option to set the desired Id field. For clarification I put a fragment of the mapping file for my typed view:

LLBLGen produces: ... public EmployeeListTypedViewRowMap() { Table("[dbo].[EmployeeList]"); Id(x=>x.AddressHouseNumber).Column("AddressHouseNumber").Access.CamelCaseField(Prefix.Underscore); Map(x=>x.AddressHouseNumber).Access.CamelCaseField(Prefix.Underscore); Map(x=>x.AddressHouseNumberAddition).Access.CamelCaseField(Prefix.Underscore); Map(x=>x.AddressPostalCode).Access.CamelCaseField(Prefix.Underscore); ....

but I need (which I adjust manually at the moment): ... public EmployeeListTypedViewRowMap() { Table("[dbo].[EmployeeList]"); Id(x=>x.EmployeeId).Column("EmployeeId").Access.CamelCaseField(Prefix.Underscore); Map(x=>x.AddressHouseNumber).Access.CamelCaseField(Prefix.Underscore); Map(x=>x.AddressHouseNumberAddition).Access.CamelCaseField(Prefix.Underscore); Map(x=>x.AddressPostalCode).Access.CamelCaseField(Prefix.Underscore); ...

If I understand it correctly, this is not yet possible to do with LLBLGen?

It picks the first field, as it doesn't see the data as a set of entities but a flat list which might not have a unique identifying field or set of fields.

You can work around this by mapping an entity on the view instead of a typedview. For nhibernate this makes little difference, as the typedview and the entity are just poco classes. Would that work for you?

We specifically have chosen to use TypedViews for views so in our application it is clear what actions are possible on the object. Also, the templates LLBLGen uses for creating entities are adjusted. These adjustments are not relevant for views.

IMHO if there is a ID field in the mapping in the Persistence namespace, these should also be an option in LLBLGen to tell which field should be that ID field.

Is it possible to take this in consideration in a future version of LLBLGen, as it is a thread to our application, although it is well documented in our workflow documents?

zweps79 wrote:

We specifically have chosen to use TypedViews for views so in our application it is clear what actions are possible on the object. Also, the templates LLBLGen uses for creating entities are adjusted. These adjustments are not relevant for views.

IMHO if there is a ID field in the mapping in the Persistence namespace, these should also be an option in LLBLGen to tell which field should be that ID field.

Views don't have ID fields, that's the problem . The only thing we can do is tell nhibernate some field is the ID field. In case of when you map a typedview on a table, then yes, there's a set of pk fields and we can choose that, but that doesn't help with views. With views, it's not always possible to select a field or group of fields which are the key.

We do have a way to define new settings in the framework setting file for nhibernate so these settings show up for the field in the code gen info tab. But that's a bit cumbersome, e.g. you have to select each field and then check a checkbox. It can however bring you exactly what you want. This would work in situations where there is a compound PK for the view, e.g. you join multiple tables and a group of fields is the unique key.

Another way is to specify distinct with the query you use, this might also help, as nhibernate doesn't do that by default.

Which way would work for you best?

Is it possible to take this in consideration in a future version of LLBLGen, as it is a thread to our application, although it is well documented in our workflow documents?

If something doesn't work in today's version, we fix it. If it's a small change, e.g.a template adjustment, we'll do it right away. If it's a bigger feature, we'll move it to the next version.

We do have a way to define new settings in the framework setting file for nhibernate so these settings show up for the field in the code gen info tab. But that's a bit cumbersome, e.g. you have to select each field and then check a checkbox. It can however bring you exactly what you want. This would work in situations where there is a compound PK for the view, e.g. you join multiple tables and a group of fields is the unique key.

Another way is to specify distinct with the query you use, this might also help, as nhibernate doesn't do that by default.

Hi Otis,

I want to be able to to let LLBLGen remember which field it has to set as ID field. It isn't problem if I have to do that once in LLBLGen, as long as I generate new code this chosen field stays the ID field. Is this the same as your first mentioned solution?

Yes, that's option 1. We scheduled a feature for this in the next v3.x version. If you need it today, first try to specify Distinct with the NHibernate query, to see whether that solves the duplicates issue. If not, we've to guide you through a custom .frameworksettings file and an adjusted template to get this working today. (see SDK docs if you want to try it yourself)

I have marked the thread as done, since we can wait on the next release of LLBLGen.