I know how to name tables and specify schemas in the OnModelCreating() method based on the classes that map to them. I.e.,
modelBuilder.Entity<Customer>().ToTable("Customers", schemaName: "Ordering");
But what about many-to-many relationships that result in an auto-generated associative table?
Nevermind, found the answer here:
Mapping association tables in EF 4.1 code first
For some reason, I didn't encounter this on my original search for existing posts.
Related
I want to archive some of my entities as other entities. For example : a Colle entity as to become a BanqueColle entity. These entities don't have exactly the same fields. Thing is I can't use Doctrine ORM because I have a table with 1M records in it.
I succeeded in doing that with some SQL queries. But to do so, I had to keep the Ids from the initial table to keep all the links between these entities.
I just thought about a problem : next time I'll archive my entities, I'll have some Ids already in archived table. How can I get past that ?
Or do you have a more elegant way to archive my entities than keeping all Ids ?
Either you should have Entities that can be mutated to "archived" status, or you have other entities, that might be created from your former entities, for example, accepting Colle entity in constructor and saving and formatting its data.
These new archived entities might as well store IDs of Colle entities.
I am working on extending the existing project which has been in production for couple of years and I need to extend a few existing entities, lets call them a,b,c,d.
When I now think about the designing of a database all the a,b,c,d should have some sort of inheritance, but changing the schema too much is impossible at this point.
Now all the a,b,c,d have their own primary keys but they all have to implement certain interfaces like - "bookmarkable", "taggable", "viewable" etc.
Would it make sense to keep creating tables like
a_saved, b_saved, c_saved, d_saved or a_tags, b_tags, c_tags etc to model the relation? But then again.. I would have to create THE SAME code to handle each of the scenarios where the only difference it's the table name!
I think better solution would be to create an new table - lets call it "object" and try to model some inheritance - for each entity create an entry in the "object" table and store that id in it's table and then create one relational table to map object_tag relation.
Does this sound like feasible solution or possibly error-prone and will bite me in the feature?
A similar solution to your second idea would be to create a single table that maps an extension by a combined (entity type, entity ID) key. See here for a sample schema and query: http://sqlfiddle.com/#!9/3c0235/1/0
I'm a new to Grails and have started a project, but I'm having troubles finding out what is wrong:
The project is already connected to my database (SQL) and it has a few many-to-many to relationship with more than 1 "parameter", like this:
static hasMany = [rules:AvaliateRules,professors:Professor,candidates:Candidate];
I run the application with no problems, but when I used show tables the transaction tables weren't all created. It just created the last parameter's table (candidate).
Any idea about the reason and how to fix it? everywhere I checked, people did the same as me and had no problems with the tables. I'm using grails 2.4.4 version.
I don't think that your current domain has many-to-many relationship with all entities that you mentioned. It might be a one-to-many relationship. Let's say your current domain is "DomainA". If only other domain like AvaliateRules,Professor has "DomainA" in hasMany then it makes it a many-to-many association.
In one-to-many association, only a column is added at the child level(many side) which contains a parentId to denote who the parent is.
I have a LINQ-to-SQL data context in which two tables exist with different names but identical structures. One table (called CallRecords) holds live/current data, and the other (CallRecordsArchive) holds older records - but with the same field names as the live one.
With the basic mapping LINQ to SQL creates two classes CallRecord and CallRecordsArchive - but since they are the same I'd like to avoid this if possible? That way I don't have to write two queries for each instance?
I did consider creating a JOIN view but with millions of rows in both tables it would be a performance nightmare.
The way I've dealt with this is to create an interface for the common aspects of both tables and have both of the generated classes from your data context implement that interface through the use of the a partial class definition. This way when you want to deal with the type as a single concept you can always refer to it as the interface.
try to use inherit for this issue
check this link for more details.
one more
I hope it is help you.
I'm playing around with LinqToSQL using an existing multi-lingual database, but I'm running into issues mapping a fairly important one-to-one relationship, so I suspect I am using the feature incorrectly for my database design.
Assume two tables, Category and CategoryDetail. Category contains the CategoryId (PK), ParentId and TemplateId. CategoryDetail contains the CategoryId (FK), LanguageId, Title and Description (in the appropriate language), with a combined PK of CategoryId and LanguageId.
If I drag-and-drop these tables into the LinqToSQL designer, the resultant object model has Category with a collection of CategoryDetail objects, which should never be the case. I'd like to be able to filter on LanguageId at the DataContext level, meaning that the whole Category is encapsulated within Category.CategoryDetail, not all language version encapsulated within Category.CategoryDetails.
This database worked fine on my old object library (an old-school custom BOL and DAL), but I fear that LinqToSQL would require this to change in order to give me the required result.
What is the best way to make this relationship (and language filtering) as seamless as possible?
You can view properties of the association. (Right click on the line representing the association and show properties.) The properties will tell you if it is a one-to-one or one-to-many relationship. This is reflected in code by having either a single entity association (one-to-one) or an entity set association (one-to-many).
I would have to assume cant be a true 1 to 1. Sounds like you have a PK of CatID and Lang ID on the Cat Details table. That would explain why its putting a collection. I could be wrong as you didnt mention the PK's of the CatDetails table
EDIT: A combined Pk of CatID and Lang ID makes that a 1:m relationship, and Linq to SQL is actually doing the correct thing. The only way it could possibly be a true 1:1 is if you had a lang ID on the cat table as well and that was part of the FK. I htink you may have to rethink what you want to do, or how you want to implement it.
I think LINQ to SQL models the database structure directly.
You have two tables so it creates 2 objects.
Have you had a look at LINQ to Entities this allows you to create another layer above the database strucure to make for more readable classes.
Since you don't have a 1:1 relationship the mapping alone will not provide the desired functionality. However it is easy to provide a method in the parent auto-generated class that does the job:
public partial class Category
{
public IEnumerable<CategoryDetail> GetDetailsByLanguage(string langID)
{
return this.CategoryDetails.Where(c => c.LangID == langID);
}
}