Why can't I create a 1 to many relationship without a primary key? - linq-to-sql

I've been messing with the Design view of my DBML class for hours now. I have one class, call it A, that has a 1 to many relationship with B, C, D, and E. In the generated code I can see that Class A has generated
private EntitySet<BB> _bb;
private EntitySet<CC> _cc;
private EntitySet<EE> _ee;
But it hasn't generated one for D. Finally for giggles I added a primary key to D; all the other classes had one except for D; and NOW it's generating a EntitySet _dd. But why is this? I don't need that table to have a specified primary key.

I assume you are using LINQ to SQL due to the .dbml files. LINQ to SQL (and Entity Framework to some degree) struggle with tables that do not contain primary keys. Specifically, the table needs a primary key to implement INotifyPropertyChanged (the interface that tracks changes for a specific identity... how can an entity be tracked if it does not have a primary key?). A good example of why this is needed can be found here.
https://social.msdn.microsoft.com/Forums/en-US/f3b216d2-fa06-49a1-a901-11702e80b38c/linq-to-sql-table-doesnt-have-primary-key?forum=linqtosql
As a follow up, is there a specific reason why the table does not have a primary key? Does it not represent a entity in your data model? If it is a "lookup" table perhaps you can wrap the functionality in a stored procedure and then call the stored procedure via LINQ to SQL.

Related

IS_A relationship primary key validation rules

So I am building a database for a police station in access. I have a reports super-class that is divided into several sub-classes.From what my books tell me the supper-class should be the one with the "ID" that is the primary key
and that the ID should be passed onto the sub classes so that there are no 2 sub-classes with the same ID .How do I make a validation rule that doesn't allow to make a new sub-clas report if that ID doesn't exists or is being used by other sub classes
There is no way insertion in a table can check whether that primary key is present in another table apart from either forcing this constraint through business rule or by using DB Trigger.
You need to analyse your DB Model again and try to identify a good design.

Entity type not created for table with composite key

I'm using VS 2010, Entity Framework 4.3 and MySql.Data.Entity v6.3.5 to work with a MySQL DB with a couple dozen tables. I use the ADO.NET DbContext Generator.
Everything works well enough other than two tables don't get Entities created for them. Both have a similar structure in that they have a composite key composed of foreign keys to other tables. So, one is a region_flavor table that maps the (ice cream) flavors assigned to a particular sales region. It looks like so
region_flavor
-------------
RegionId INT(10) PK NN
Flavor VARCHAR(64) PK NN
RegionId is a FK to the regions table and Flavor is a FK to the ice_cream table.
There's another table with essentially the same situation.
When I do an "Update from Database", I see that there is, in the Model Browser, the table region_flavor listed under my IceCreamModel.Store\Tables / Views folder. But under my IceCreamModel\Entity Types folder there's no Entity Type.
I don't receive any .edmx errors when I do the update from the DB.
Perhaps I'm missing something here. Ideas?
I can post more info if that's helpful.
It is normal behavior. This is junction table used to model many-to-many relation in database. If it doesn't contain any additional column EF doesn't need to map it to entity because many-to-many relation is modeled directly and translated to table rows internally by EF.

Entity Framework 4.2 - How to realize TPT-Inheritance with Database-generated Primarykey Value?

I want to use the EF (4.2) in the following scenario:
There exists a database already (so I chose the database-first approach) and it is a SQL Anywhere DB.
I want to use persistence-ignorant business objects, so I use the DbContext Template to generate POCO classes from the EDM.
There is one simple inheritance hierarchy among my entities: an abstract base entity and two concrete derived entities.
In the database there is one table for each type of the inheritance hierarchy (Table-Per-Type Strategy).
Each of these three tables has a primary key column (Id, type:integer), and the association of a concrete entity to the base entity is done by having the same Id in both tables (that means that the primary key (Id) of the concrete type tables is at the same time a foreign key to the base table; a pretty common approach I think).
I had to define the Inheritance manually in the designer, since the EDM assistant does not automatically recognize, that is want to have an inheritance association between the described entities.
Until this point there wasn't any bigger problem. Now to the issue at hand:
There is a restriction for the database I use: Primarykey values have to be generated by the database, using a database function.
I want to call this function in a before-insert-trigger defined on the base-table.
To let the entity framework know that a value is generated by the database, I set the StoreGeneratedPattern property of the Id Property of the base-entity to Identity (As I understood, this is the way to tell EF to get the generated value after inserting a new instance of an entity).
When I create a new instance of a derived entity, add it to the corresponding DbSet of the DbContext and call SaveChanges on the context, a DbUpdateException is thrown, stating that a foreignkey constraint is violated.
By checking the request-log of the DB, I see that the base entity got inserted in the base table, but on inserting the row in the derived table, the above mentioned error occurs, because it obviously doesn't use the newly generated Id of the new entry in the base table.
Since I don't think there is much I can do on a database level against that, the question is, if the EDM or DbContext can be configured (or modified) to insert the base row first, then take the generated Id and use it for insertion of the derived row.
I know there are several way to avoid this situation (not using inheritance, using a stored procedure to insert a new derived entity, calling the id-generating db-function before inserting and set the Id property myself on the entity), but at the moment the above-described behavior would be the most preferable, so I want to make sure not to overlook something before deciding for any "plan B".
Any suggestions on this topic are much appreciated,
Thanks in advance.
Here is the code of the trigger:
ALTER TRIGGER "TRG_GENERATE_ID" before insert order 1 on
BASE_TABLE
referencing new as NewEntry
for each row
begin
declare NewID integer;
set NewID = F_GET_NEW_ID('BASE_TABLE', NewEntry.SOME_OTHER_ID);
set NewEntry.ID = NewID
end
The function "F_GET_NEW_ID" is called in the trigger to generate the new ID for a new entry in the base table. It has two parameters:
"Tablename" -> The name of the table for which a new ID should be generated,
and a second parameter that takes the value of a standardcolumn in all tables of the database (it is required to generate the new ID).

Table relationships in LINQ to SQL

Assume I have a two tables, A and B. Table A has a primary key called A_ID of type int, and table B has a foreign key called A_ID.
When I add the two tables to a LINQ to SQL data context class it correctly creates the classes and the association between them.
My question is, class B will have a property of type int called A_ID. It will also have property called A, of type A.
Now, if at runtime, I make a LINQ to SQL call which populates an instance of B, B.A_ID and B.A.A_ID will be the same value. What is stopping a developer from making some mistake and putting a different value in B.A_ID than is in B.A.A_ID?
In a database you couldn't do this because of the foreign key constraints, but how do the LINQ to SQL classes enforce those constraints on the client side?
LINQ to SQL, when attached to a relational database, is really just building SQL for you and so if you do something illegal in the database (like violate a foreign key constraint) it's the database that is really stopping you, not LINQ itself. And constraints in LINQ to SQL itself are just retreived from the database.
So, unless you're talking about attaching it to an XML segment or the like (and I don't see that your question suggests that) then LINQ really isn't enforcing anything in and of itself. It's really just a very sophisticated codewriter.
Edit: I said that LINQ to SQL is just a codewriter, but I should note that the metadata that lets you use the strong typing, etc. is nice. I don't mean to belittle the product.

Linq To SQl Reference Keys behavior?

I have a database with some references,
An example is a Customer Table has the AddressId integer column, and an Address Table has the Idenity Auto Generated Id column. I reference these as primary the Address "Id" and the Customer "AddressId". Now when i generate the dbml file or use SqlMetal, i get in the Customer entity two properties for the reference, AddressId that is an int type, and Address as an Address type. This is confusing! can i get rid of this functionality?
And how could i turn off pluralize? Thank you.
You cannot turn off the 'feature' of generating both the foreign entity reference and the foreign key reference. L2S uses both of them in conjunction. So, you're going to have to get used to it. It was a little hard for me to get used to at first, but I then realized there are benefits to having both.
If I recall, SQLMetal has a command line option to turn off pluralizing, but cannot say for sure. I wrote my own code generator that generates my entities and data context object and I have it generate non-plural names.