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.
Related
I am using a database-first approach to a third party database that I cannot change. The database has two tables that should have a constraint defining their primary/foreign key relationship. The constraint is missing so the entities generated do not have the relationship. Is it possible to add the entity relationships to the scaffolded entities without losing my additions if I need to scaffold again (due to an upgrade etc)?
I've thought about creating a custom partial class file extending the existing entity but this will not work if the existing entity already has a constructor. I need a constructor to instantiate a HashSet<T> of the other side of the relationship. I've also thought about using inheritance but not sure if that will work well with the existing entity.
Update: It seems like easiest solution may be to instead use linq join syntax and not provide the relationship in the entities but I'll leave the question up in case anyone has a good solution and a use case where it is beneficial.
I have an old database, where tables have no primary-foreign key relation. And I can't change/add relations in the database now.
I'm trying to use Entity Framework or an ORM tool. Please tell me if it is possible to use any ORM in this kind of situation? If not, what will be appropriate way to design my DAL?
I'm using ASP.NET Web API.
Have a look at Dapper.NET
Official Github page here
Intro CodeProject article here
Since it just basically "hydrates" whatever an arbitrary SQL statement returns, it'll be able to handle even such a crappy database design - as long as you can express your query in T-SQL, Dapper can build you some nice .NET objects for it.
Dapper is also the lightweight ORM used by Stackoverflow itself :-)
As long as your database tables have primary keys, you will be able to use Entity Framework for the basics like mapping your table rows to C# objects and doing LINQ-to-Entity queries.
However without foreign keys, you won't be able to take advantage of navigation properties. This will mean that a number of things will be more manual and long-winded than if you had proper foreign keys but you should still be able to do any data manipulation that you want.
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
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...
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.