EF TPT Indexes on derived tables - entity-framework-6

When we use TPT inheritance in Entity Framework, it creates 2 indexes on the pk field of the derived table.
One PK - Clustered Index
Second - A non-clustered Index.
Is it done with a purpose OR an error.
If it is a purpose, whats the purpose?
If it is an error, how can I correct this?
Thanks

It's a side-effect of the derived PK to be also the FK. Entity Framework automatically indexes FK columns.
It's not a bug. It's just not being overly smart. I think.
I believe you can drop the second index as it's giving you anything in terms of performance.

Related

core data - relationships, fetching and inserting

I'm using CoreData for the first time in one of my project. My table involves FOREIGN KEYS and since CoreData doesn't support FOREIGN KEYS, I'm having some issues.
Below is the structure of my tables.
My Problem is the establishment attribute.The establishment attribute is supposed to hold the name of a particular facility from the Facilities table. However, since it's a relationship, Xcode expects a Facility rather than just a name of a facility (NSString).
Is this possible, or am I just mixing up FOREIGN KEYS with RELATIONSHIPS in CoreData? How would I solve this problem?
Thanks in advance.
A relationship is not a property, so it does not have a type. In the model editor you add a relationship explicitly.
From your diagram, I see that you did not set the inverse relationship. There needs to be a corresponding relationship from name to the Assessors entity. (Set the "Destination" to Assessors in the model editor.)
I would also suggest to rename a few items.
First, use singular: Assessor, Facility. These are objects (comparable to classes), not tables.
Second, because your name attribute refers to an assessor, call it assessor, and similarly call its reverse relationship facilities (it is a to-many relationship in this direction, so the plural is appropriate).
If you need the name of the assessor of a facility, you use
facility.assessor.name
This should make it obvious why you do not need foreign keys. Indeed, I would urge you to think that it is not Core Data that does not support foreign keys, but that it is the traditional relational databases that do not support relationships!

Join queries in Doctrine on tables without specified relations

I have two tables that do not have a relation defined with each other in the schema.yml.
However, table 1 has a foreign key reference to the primary key of table 2. Clearly, I goofed up by not designing the database well, but now it's mitigation time.
I must do a left join between the two tables coupled with a where clause that will retrieve the select rows I want. And to do this, I do:
Doctrine_Query::create()->select('t.*, l.lid')->from('Taxonomy t')->leftJoin('t.Cid c') ->leftJoin('c.Lesson l')->where('t.section = ?','Critical reading');
This should typically do it, but it does not because what it returns is all the rows from taxonomy table irrespective of the where condition. I am thinking, is this because of the relation not being specified in the column? That would be ridiculous cause the query works, only in a doctrine context it does not.
Thanks
In doctrine you can only join using the relations you defined on your schema, this is a know limitation. You may use the Native SQL feature as a workaround.

Why does Database First EF skip mapping some tables?

I'm using Entity Framework 4 and with a Database First binding, and EF is not generating the entities for a few of my tables. I'm not getting any errors, and no matter how many times I select the tables to generate from the "Update Model from Database" popup menu on the design surface, the same tables are still missing from the model.
I get no errors in the wizard. They just don't get generated. Any clues?
EF requires a primary key on the table. EF will not map tables for which it can't find or derive a primary key. If all columns are nullable, it can't assume a primary key. If one or more columns are not nullable, EF will evidently derive a primary key for the table.
EF will ignore table without primary keys.
Options I can think of:
Did you check the box next to those tables?
Did you previously add them, then delete their entities but keep the cache of the tables?
If so you can remove them from entity browser window and re-add them
or manually add entities and define the table they map to in mappings window.
Perhaps tables were classified as relations instead of entities?
You can manually add the entities and choose the table they map to in mappings window.
Actually, in my case, it doesn't work because I was using a hierarchyid field as a primary key and EF doesn't work with this field type, so, it didn't import the table, because a valid PK is required.
A possibility is when you're using tables with some different field types, as hierarchy in SQL Server.
Without Primary Key Tables where Skip Automatically on EF, OtherWise You Fix a Value as Not Null.

EF4 - Is there any way it can be made to support unique indexes

My primary key is a guid column and I would like to have a unique index on another column in the table. I read that EF4 doesn't do anything for unique indexes. My question is: Can I add to a partial class any code that would allow me to check for non-unique values before my data hits the database. Currently I'm using the following configuration:
Users Desktop <> wpf Datagrid <> Observable Collection <> EF4 <> SqlCe database.
Thanks in advance.
Richard
I don't think it can do this, because to track value uniqueness entity framework requires all records from the table to be read into memory, or execute database query on each value change. It is performance-ineffective way and I think entity framework does not support this.
Supporting unique key concept is definitely in scope for the next version of EF from what i have heard. But uniqueness will be enforced at the objectcontext level meaning what is currently tracked in the object context. This is the same concept for cascading delete which currently works in EF4. In cascade delete, EF only enforces cascade deletes to entities that is currently loaded in the objectcontext. It does not try to load everything from the database.

Handling lookup tables in Entity Framework v1

I am just getting started with Microsoft's Entity Framework, using it for an MVC project since MS seems to be really pushing it, and I'm running into some issues. In my database there are multiple lookup tables tied to a single table via foreign keys. Within the entity framework I am trying to combine these into one so that I have a simplified single view for this data in my model. However, this doesn't seem possible from the designer view. Is there something obvious I'm missing? Is there a way that I can edit the edmx file manually to produce this sort of model?
At the moment, Foreign keys and lookup tables in Entity Framework are a PAIN.
EF with LINQ makes getting your data super-easy, and on the surface it looks easy to update, but with lookup tables things get difficult (for now... read on...)
I'm not sure how you would "combine" your lookup tables into a single table. If each table contains a different type of "lookup entity" then IMHO they should be represented separately in your EDM. I'm guessing you're having headaches updating a record's foreign keys to the lookup tables. That's because it is a headache.
Changing foreign key values:
MyDBEntities _db = new MyDBEntities();
//get a Person
MyDBEntities.Person person = (from p in _db.Persons
where p.Id = 1
select p).First();
// This sets the foreign key value in the Person table on the PersonType field
person.PersonTypeReference = new EntityKey("MyDBEntities.PersonType", "PersonTypeId", 3)
The next release version of the Entity Framework will have a new concept called "FK Associations." This will bring back the sanity of setting the foreign key value directly rather than having to create and set an EntityKey.
HTH.

Resources