Does LINQ to SQL provide out-of-the-box polymorphic associations as ruby on rails active record does? If not, is there any workaround to manually map those associations?
Agreed. I found no possible way of doing this nor using the designer nor by hand appending class/method attributes. Moreover is not possible to have foreign key constraints for polymorphic associations. I discarded this option, thanks.
EDITTED
SQL Server won't allow you to have a foreign key relationship on a column that is not a primary key or doesn't have a unique constraint (or index) on it. There doesn't seem to be any restriction on having multiple tables use the same column in the child table as the foreign key. The DBML designer does discover these relationships and will create associations to both parent tables when you import the table. It appears however, that the designer-generated code will only be generated for one of the associations. That is, the designer shows the associations properly, but the code for all but one of them is omitted. Further, the extensibility methods and property settors don't seem to get defined properly in the designer-generated code either.
The same seems to be true if you add the associations by hand in the designer. Only one of the actual associations is implemented in the code and the other parent class's code seems irretrievably broken. It's possible that you may be able to use partial class implementations to add in the required functionality to match what the designer would generate, but I haven't tried this.
Also, LINQ2SQL doesn't support many-to-many relationships out of the box. You're limited to 1-1 and 1-many without writing the code yourself.
Related
Is there a way to find which class is ,,Parent" and which is ,,Child" in FK relation? I can't think of a method to reliably accomplish it by using reflection and I don't have any idea how to do this with metadata without parsing strings. I am looking for something which would return Type of a ,,Parent" object.
The Entity Framework Mapping Api is one way to do it. I think it is technically possible to do what you need directly against EF but the code is a nightmare. I recall just trying to look up the primary keys directly against EF and it was convoluted. This library will make you life a lot easier.
The only one thing it does not do is show you the child relations, just the Foregin Keys. So you will need to implement your own logic to get child relations.
I'm building a small db-cleaner app for a QA sql server database. Naturally, I need to delete table rows with dependencies on them.
T-SQL cascading abilities are very limited, so I've tried using NHibernate to simplify matters. But, the only way I found for this was to create a collection for each dependency
in the object-to-delete, and mark that as cascade=delete.
That means creating many, many collections (both in the hbm file and in the C# object) which I don't need for any other purpose. Which makes this method as complicated as just using SQL.
Am I missing something? Is there any easier, more generic way to perform delete-cascade?
Thanks.
EDIT: Just to be clear, I avoid changing the foreign keys in the DB because it's a QA DB, designed to be identical to the production DB.
Eventually I found out a generic way to do the deletion:
This guy wrote a recursive SP which does all the work for you:
http://www.sqlteam.com/article/performing-a-cascade-delete-in-sql-server-7
Needed a little touch-ups (since my DB uses schemas) but works like a charm.
I suppose you have foreign keys defined between related tables in your database ?
You can specify at the foreign key level what should happen with related records when a parent record is being removed.
Check out MSDN for the cascading options, and how to define them:
Cascading FK constraints
Foreign Key Constraints
I generate Entity Data Model in Visual studio from the database.
However, I noticed that it does not generate neither relationships nor navigation properties from some foreign keys. It occurs when the foreign key contsraints are defined with the disabled option Enforce Foreign Key Constraint, like in the following exhibit (from SSMS).
Is there any way to deal with this? Unfortunately I cannot alter my database schema.
You can add them manually from the designer but it can have some consequences depending on the version of entity framework yo are using.
If you simply add association from the toolbox it by default creates independent association. Independent association must be mapped to the database counterpart. It means that you must manually open EDMX and cheat EF by modifying SSDL (you will add relation to SSDL part manually which can be quite hard task - follow SSDL reference: AssociationSet and Association elements). Now you can map the relation in the Mapping details window of the designer (you will also have to modify entities because FK property mustn't be mapped to the entity when independent association is used and in case of many-to-many association you will have to remove entity for junction table). EF will believe that this relation exists in the database. Once you modify SSDL manually you cannot use Update from the database any more. It will delete all your manual changes.
If you are using EFv4 you can use foreign key association (complete differences between those two types is described here). Foreign key association is not mapped but it cannot be used to define many-to-many relation.
The problem will occur if data in the database doesn't enforce the relation (which can happen because FKs are disabled). In such case your application will not work and there will be no way around this except repairing data integrity in the database or removing the association from the model.
The best solution for you is turning on FKs in the database!
Unfortunately You have to add those by hand in the model. That's the power of OR Mapping. Model can look different (better) than database.
Is it possible in EF4 to change conventions for a whole DbContext rather than on a per entity basis?
Currently when I run EF4 queries I'm getting an error on foreign key relationships
Invalid column name 'Account_Id'.
The table being queried (User) has a column named AccountId which is a foreign key to the related table (Account), if I change the column to Account_Id, it solves the problem.
However, the issue is that I don't want to do this on every table. I've set custom conventions no problem using NHibernate, so hopefully its as simple in EF4.
I don't think there is support for global settings. You can use fluent API, as you probably know, but this works for single entity only. I've decided to keep EF4 conventions and use xxxID for primary keys and table1_table2 for linker tables. It's easier to swim with, not against the current ;-). You might want to fire reflector to check the code for an easy way to hack it...
I have two different dbml diagrams reflecting my Linq-To-SQL classes. (This is necessary, because they appear in different projects.) One of the objects in the one diagram needs an association with an object in the other diagram.
How do I do it?
Actually your two diagrams meens two different data contexts will be generated. I also guess your using SqlMetal on the diagrams to generate your entities.
You will need to include all associated objects in one diagram or the datacontext wont be able to retrieve that relationship from the database for you.
Another option is using custom entities and an XML mapping file.
I had a concern about this issue myself, which is why in my case, I put all the entities in one context. The context is too big and complex to use in the designer now (it takes about 20 minutes to load and probably has more than 100 entities), so we use SQLMetal (the command line form of the DBML compiler/generator) to build it instead. The DBML itself is maintained with (generated by) a tool I created for designing our schema. It's not exactly an answer to your question, but is one way to deal with this concern.
As it turns out, the easiest way I found to accomplish this is by forcing the relationship. I created my own partial class to match the class containing the FK, and just mimicked the generated code that I found for other relationships.
This has only one shortcoming AFAI can tell: there's a piece of generated code in the actual foreign key field's set property that should throw an exception if you try and set the value when there's already a value in place:
if (this._Parent.HasLoadedOrAssignedValue)
{
throw new System.Data.Linq.ForeignKeyReferenceAlreadyHasValueException();
}
But I'm prepared to live without that, as long as I know that I shouldn't be setting the FK field explicitly.