I have a pretty simple model with a customer and Item, with one-to-many relation between them (One customer can have many items). I used the designer to place my entities and I do see an association between them in the designer. Its xml reflects this:
<Association Name="vgMfiCustomer_vgMfiItem" Member="vgMfiCustomer" ThisKey="CustomerLink" OtherKey="Customer" Type="vgMfiCustomer" IsForeignKey="true" />
Trouble is that in the designer.vb, there's no mention of this association, So I cannot say Customer.Items in my code. Did I miss a step in generating the model? Or maybe I need to add the navigation property manualy? I come from EF.NET background, where the navigation properties are created automatically.
It sounds like you have the association setup for one direction, but not the other. In the dbml, there should be an Association element for each type. You may want to try removing the association in the designer and re-adding it.
Ensure that both tables have a property marked as "Primary key" (in .dbml schema)
Related
In the (MySQL) database, I'm storing a view hierarchy, with each row in a table referring to a single view. There are several types of views, but they're stored in the same table.
In the application code, each type of view has its own class. Each row in the database instantiates one of these classes.
How should I refer to these classes from the database, so the application knows which class to use?
I can think of several possibilities:
Just specify the class name directly in the table, but this has the disadvantage of having to change lots of rows if the class name changes (which can be done in a single query if required).
Have a separate table storing class names, and use foreign keys to point to the row storing the correct class name. In this case, I could forgo having an ID field in this lookup table and instead have the class name as the primary key and target foreign key, and rely on a cascading UPDATE if the class name changes?
Are there better options available?
If I understand correctly you want to maintain an association between view-names and class-names.
Your bullets suggests, that there can be more than one view for the same class and both of your suggestions would work. The second bullet has the advantage that you can change the class name with a single update. But that doesn't buy you much, because as soon as more than just a single class-name changes, i.e. when the association itself changes, you need to update more than one row.
You might even create a separate table, holding this association. This would be the model for an n:m relationship, which is too general, so you'd have to place a unique constraint on the view-name. Essentially this will just factor out the concern of associating view-names with class-names and allow you to change this mechanism entirely without having to mess with your tables (except the one holding this association).
But actually I would not store any of this stuff in the database
(I also find it irritating that view-names are stored in the database and not in the application logic). The fact that there are class-names, should be of no concern to your database. This is application logic and it should be handled there. So what you need is a way to instantiate an object when the view-name is known. This looks like a classic factory to me. After all, if a class name changes, it is a change in the application code and life is easier, when all resulting changes lie in the application code as well.
I am using Entity Framework to create a Model, I am pretty new to the Entity Framework so bear with me.
I want my database to always be the end all be all of what gets generated, so I dont wnat to make modifications to the model itself. I want to amke all modifications to the database and just hit "Update Model From Database." This has been working swimmingly!
However If I have a one to one relationship between two tables, and I have a foreign key constraint set in the database, I get a navigation property in the child table that goes back to the parent table.
So if I want to access the parent from the child I can do child.parent.fieldName
That sounds great in theory but my issue arises when I need to serialize the object for JSON created by the entity Framework. I always get an error because it tries to serialize the parent object along with the child object. which usually has an invalid state at this point so.. A) it cant be serialized and B) I wouldn't want all that extra info anyway.
Am I misconfiguring the database in some way? is there a way to have the database specify that I only want Parent.Child Navigation properties in the model? and not Child.Parent?
Am I misconfiguring the database in some way? is there a way to have the database specify that I only want Parent.Child Navigation properties in the model? and not Child.Parent?
No. Database knows nothing about your intention to use some tool on top of it. If you don't want the navigation property you must change it in EDMX by deleting it but sometimes you want the property but you also want a serialization. In such case you must either modify strategy used to generate your classes (if you are not using T4 templates it will be quite hard) to use some special attributes dependent on used serialization API to mark some properties as not serialized.
The correct approach is not serializing entities but creating special data transfer objects filled from entities which will contain only properties/data you are going to serialize so you will not get into this problem.
I'm new to Linq2Sql and to learn it I'm trying to setup reports using Linq2Sql against the FogBugz tables. But, since the FogBugz tables don't have any true Foreign Key relationships, LinqToSql isn't finding the relationships and I can't figure out how to create them through the Designer. So, is there a way to do this manually? If I do it manually and then later decide to add another table, will everything I did be overwritten?
You can add relationships (aka Associations) in the SQL2LINQ designer by right clicking the white space in the designer, choose Add -> Association.
Choose your parent and child tables (classes), then link the properties on the tables accordingly using the grid that appears below the dropdowns for parent and child classes
I'm creating a .dbml file from a database. My "property" table has foreign keys to the "county" table and to a "propertysource" table.
When code is generated, Property.Source is defined as a PropertySource type, but Property.County is defined as an int, instead of a County type.
I'm afraid I don't have the experience with LINQ to SQL to understand what's happening here or why that is or how to fix it. I can't find anything obvious about my schema that might cause this. How can I get the automagically generated code to recognize the County property of the Property object is a County type?
When you click on the Property in the DBML file, you can modify it's Type using the Properties window. In the Properties window, there's a field for Type. You can select some of the standard Types from the dropdown, or enter in your own custom Type using it's full name, ie. "MyProject.Location.Country.CountryType", etc.
Be sure to rebuild your project before you try to access this in IntelliSense. Hope this helps!
When you open the dbml designer make sure you have a diagram that shows two arrows from the Property class: one arrow going to the County class, and another going to the PropertySource class. Also, you should have those three classes in your designer as well.
If you don't see the object model that way then there is probably something wrong with the way your database schema is set up.
I would check to make sure your foreign keys are set up correctly.
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);
}
}