Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > Designer> when an entity is mapped onto a table, it requires at least on identifying field
 

Pages: 1
Designer
when an entity is mapped onto a table, it requires at least on identifying field
Page:1/1 

  Print all messages in this thread  
Poster Message
kalyan kumar
User



Location:

Joined on:
19-Jul-2010 07:45:27
Posted:
22 posts
# Posted on: 27-Jul-2010 07:47:45.  
hi,

I got v2.0 llbl gen project. I successfully converted that to v3.0 llbl gen project. when I tried to validate the v3.0 project its giving following error.

The entity 'xxxx' is mapped on to the target 'dbo.xxxx' however 'xxxx' doesn't have any identifying field set , while the target is a table. when an entity is mapped onto a table, it requires at least one identifying field.

After doing some debug i found that the table had no primary key. So I defined one column(id) as identifying fields using designer. I got the following error.

Mapped Target - The isNullable flag on target field 'dbo.xxx.id' is set to 'True' while the IsOptionalFlag of the mapped field 'id' is set to 'False'.

Unfortunately the table doesn't have any not null columns to define identifying fields. Earlier v2.0 project allows these types of table to add to project . So I used those table entities In my application. now v3.0 is not allowing..So i can't use those table entites in my web application. But I need those.. Please help me out.

thanks in advance,
kalyan.
  Top
Walaa
Support Team



Location:

Joined on:
21-Aug-2005 16:03:48
Posted:
13799 posts
# Posted on: 27-Jul-2010 08:49:42.  
Please go to the "Field Mapings" tab and select the field.
Then hit the "Edit Field" button, and then remove the "Is nullable" check.


  Top
kalyan kumar
User



Location:

Joined on:
19-Jul-2010 07:45:27
Posted:
22 posts
# Posted on: 27-Jul-2010 13:44:43.  
Is it mandatory to define the identifying field ? or can we bypass that error with out defining identifying field?
  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
34993 posts
# Posted on: 27-Jul-2010 20:32:32.  
It's mandatory for tables.

You can do two things:
1) create a typedview instead of an entity for these tables. In v3 you can map a typedview onto a table. As these tables can only be used in a read-only fashion anyway, it doesn't make much difference in practice
2) create a view for the table (this leaves the table untouched) and map the entity onto the view instead of the table.


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
cerberis
User



Location:

Joined on:
20-May-2011 14:23:12
Posted:
86 posts
# Posted on: 20-May-2011 14:32:43.  
Currently I evaluating version 3.1..
My company had version 1.0.2005.1 which is quite old, but still very powerfull. Migrations is quite complex, because we made many custom templates.

Now I am evaluating new LLBL version for next project.. Old LLBL version generates tables without any problems. Hovewer, the new one has these "identity" errors.

I really do not want to go through all tables and add identies which in fact are not used at all... (I know its a bad design, but currently I do not want to touch database) .
Also I cannot make views, because there are inserts to them..

So my question, is there any way to avoid such kind of validation?

Otis wrote:
It's mandatory for tables.

You can do two things:
1) create a typedview instead of an entity for these tables. In v3 you can map a typedview onto a table. As these tables can only be used in a read-only fashion anyway, it doesn't make much difference in practice
2) create a view for the table (this leaves the table untouched) and map the entity onto the view instead of the table.

  Top
Walaa
Support Team



Location:

Joined on:
21-Aug-2005 16:03:48
Posted:
13799 posts
# Posted on: 20-May-2011 15:13:45.  
If the table has a unique field, you may set this field to be the identifying field in the Designer.
Else you'd better use a TypedView instead of an entity.


  Top
cerberis
User



Location:

Joined on:
20-May-2011 14:23:12
Posted:
86 posts
# Posted on: 20-May-2011 15:38:22.  
Sure, I know this variant.. But sill not all has such column.. Event worse: I have some tables, which has 2 columns, both are foreign keys, no PK and no unique field..

Walaa wrote:
If the table has a unique field, you may set this field to be the identifying field in the Designer.
Else you'd better use a TypedView instead of an entity.

  Top
daelmo
Support Team



Location:
Guatemala City
Joined on:
28-Nov-2005 23:35:24
Posted:
7667 posts
# Posted on: 20-May-2011 23:08:11.  
Hi Kalyan,

cerberis wrote:
So my question, is there any way to avoid such kind of validation?

Is short, no.

cerberis wrote:
Sure, I know this variant.. But sill not all has such column.. Event worse: I have some tables, which has 2 columns, both are foreign keys, no PK and no unique field..

I know you are struggling about this. But really, this is an improvement because in the generated code, tables without PK are useless in select/update scenarios. So, the workarounds for you are those posted by Frans. Is it possible for your application to go through these workarounds?


David Elizondo
LLBLGen'ing (articles and code snippets) | linkedin | twitter
 
Top
cerberis
User



Location:

Joined on:
20-May-2011 14:23:12
Posted:
86 posts
# Posted on: 23-May-2011 07:41:17.  
daelmo wrote:

I know you are struggling about this. But really, this is an improvement because in the generated code, tables without PK are useless in select/update scenarios.


I understand your improvement, still framework should not prevent to have such cases. I would say - it should be possible to disable such validation.
We have situations, when we need only to read from such tables, because inserts are done by some triggers and so on..
And yes, I agree - its a bad design, but some old applications works in such way and I cannot change that.

daelmo wrote:

Is it possible for your application to go through these workarounds?


Not for evaluation...
  Top
Walaa
Support Team



Location:

Joined on:
21-Aug-2005 16:03:48
Posted:
13799 posts
# Posted on: 23-May-2011 10:10:21.  
Quote:
We have situations, when we need only to read from such tables, because inserts are done by some triggers and so on..
And yes, I agree - its a bad design, but some old applications works in such way and I cannot change that.


I think you are missing one point here.

If you only want read-Only dataStructure, then you should use TypedViews, these are objects defined in LLBLGen Pro Designer, and not the database.

So instead of maping these tables to Entities and generating code for entities, you should map these tables to TypedViews, and generate code accordingly.

TypedViews are used for such read-only scenarioes.


  Top
cerberis
User



Location:

Joined on:
20-May-2011 14:23:12
Posted:
86 posts
# Posted on: 23-May-2011 10:28:20.  
Walaa wrote:
Quote:
We have situations, when we need only to read from such tables, because inserts are done by some triggers and so on..
And yes, I agree - its a bad design, but some old applications works in such way and I cannot change that.


I think you are missing one point here.

If you only want read-Only dataStructure, then you should use TypedViews, these are objects defined in LLBLGen Pro Designer, and not the database.

So instead of maping these tables to Entities and generating code for entities, you should map these tables to TypedViews, and generate code accordingly.

TypedViews are used for such read-only scenarioes.


Its not always the case, when its read-only. There are also tables where it can be inserts from code or updates by some values (not by PK), using UpdateEntitiesDirectly or even deletes..
  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
34993 posts
# Posted on: 23-May-2011 11:53:19.  
If you really want this, the only option is to set IdentifyingFieldsFollowDBPrimaryKeyConstraints to false in the project properties. Then you can add the PK to the _entity_. This will not require a PK definition in the table. As you can't change the DB, you won't refresh the project anyway.



Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
cerberis
User



Location:

Joined on:
20-May-2011 14:23:12
Posted:
86 posts
# Posted on: 25-May-2011 09:02:41.  
Otis wrote:
If you really want this, the only option is to set IdentifyingFieldsFollowDBPrimaryKeyConstraints to false in the project properties. Then you can add the PK to the _entity_. This will not require a PK definition in the table. As you can't change the DB, you won't refresh the project anyway.



Thank you, this fits for my needs Regular Smiley
  Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.