I am using LLBLGEN 3.1 (June 17 2011 Build) and PostgresSQL Database 8.4.1. The Designer doesnt infer any Primarily Key for a Database View. The Devart and Microsoft Designer both set all the keys in the view to be the PK so the code can be at least generated. LLBLGEN Designer forces you to handle the Pks for the views before it will generate the code. I can understand both design approach. But I rather have an option that allow you to chose which approach.

Is there a way to set the PK of the Database View when reverse engineering the database?

Thanks,

Charlie J.

Is there a way to set the PK of the Database View when reverse engineering the database?

Could you please elaborate more on when and how do you want to handle this?

cjbiggs wrote:

I am using LLBLGEN 3.1 (June 17 2011 Build) and PostgresSQL Database 8.4.1. The Designer doesnt infer any Primarily Key for a Database View. The Devart and Microsoft Designer both set all the keys in the view to be the PK so the code can be at least generated.

They choose all non-nullable fields. Which might not be enough (i.e. unique) or might be too big. It's a situation we didn't opt for: the entity mapped onto it would have all those fields as its pk, which is silly.

LLBLGEN Designer forces you to handle the Pks for the views before it will generate the code. I can understand both design approach. But I rather have an option that allow you to chose which approach.

It doesn't force you to have a pk on a view, because that's not possible, views don't have pk's.

In the docs there's a note about this: http://www.llblgen.com/documentation/3.1/Entity%20Framework/hh_goto.htm#V1/NotSupportedConstructs.htm

See note at the bottom.

So when you map an entity E onto view V, you set the identifying field/s of E and during code generation V will get the fields in V which are the target of the identifying fields in E as pk fields.

I know a view does not have a PK. But this would force me to go through all my entities mapped to a view and set the PK. I have over 60 views and like the way that Entity Framework infer non-nullable fields in the view and set them as the PK by default and I can go in and fix it up later to be correct. The code can generate without me handling the views at that moment. With the LLBLGEN Designer and I force to handle setting the PK on the entities mapped onto views before I can do code generation. I can would like to have an option that would allow me to do it the same way as the Microsoft Designer and Devart Designer.

Thanks,

Charlie J.

Frankly I don't see the point of generating the code, when you are going to fix it afterwards.

And instead of just picking one field in most cases, you will have to de-select many fields in each view.

It's not always possible to pick fields for the 'pk': sometimes all fields are nullable (some databases report views to have all nullable fields or this is unknown), or there are no unique fields. If a view has 30 fields, having 30 PK fields is really weird and also cumbersome to use.

The problem with all-nullable fields is why we didn't support this on EF. NHibernate at least can be told to simply 'use this field' as pk, even if it's not a unique field or even nullable: the class is used as readonly anyway. This didn't work on EF.

There's much debate about this on the EF team mailinglist, as the 'pick all nonnullable fields' is not something people want, at least that's what I learned from these debates.

Thanks Otis for the explanation. I can see it from both sides. As a LLBLGEN user and Devart Entity Developer/Microsoft Designer user, if this was an option (whether right or wrong). Because I am going from Devart Entity Developer/Microsoft Designer to LLBLGEN as my Entity Framework Designer.

But I can work around the differences. I has just hope for an option to support the way Devart Entity Developer/Microsoft Designer handles views or being able to edit the templates to support it.

Thanks,

Charlie J.

We can always add an option of course. I don't have a quick fix for you at the moment though. (you could write a small plugin, which could help you with this though. Writing a plugin is easy, see the sourcecode archive which contains plugin sourcecode. The object model might be a bit overwhelming at first though, see the designer reference manual. If you want to go this route and need help, let us know.).

I'll add a request for an option for this for the next version (second highest priority, so if time permits, it's added).

Out of curiosity, what made you decide to move away from entity developer?

Thanks Otis. You are the best.

We are moving from Devart/Entity Developer because they dont have built in support for SSPI and PostgresSQL. The Open Source Driver NpgSQL has that support. We run in a Windows environment, but our PostgresSQL is on Unix.

Does LLBLGEN Designer support using Devart dotConnect for Postgres as an Entity Framework driver?

Thanks,

Charlie J.

cjbiggs wrote:

Thanks Otis. You are the best.

We are moving from Devart/Entity Developer because they dont have built in support for SSPI and PostgresSQL. The Open Source Driver NpgSQL has that support. We run in a Windows environment, but our PostgresSQL is on Unix.

Does LLBLGEN Designer support using Devart dotConnect for Postgres as an Entity Framework driver?

No, though it might work. Our driver has mapping definitions for types for npgsql, and our experience is that devart's ado.net providers are different in some cases when compared to open source ado.net providers (like which is the case with mysql's).