entity-framework-4.1

Attaching and detaching entities from context correctly in EF4.1

拜拜、爱过 提交于 2019-11-28 04:55:50
I am trying to implement caching mechanism for entities. And to use the entities correctly and seamlessly with the caching i need to detach the entity from the current context before i put it in a cache and attach it back the the new context when i get it from the cache. (My context lifetime is per http request) The requirements are that - All the navigational properties that are associated with it (which i have already populated) should not be removed when the entity is detached. I can update the cached items if i want ( so correctly attaching them to the new context is important). This is my

How to stop EF4.1 Code-First to create Culstered index for the entity PK

♀尐吖头ヾ 提交于 2019-11-28 04:45:35
问题 With the following simple entity class, EF4.1 Code-First will create Clustered Index for the PK UserId column when intializing the database. public class User { [Key] public int UserId { get; set; } public int AppId { get; set; } public string UserName { get; set; } } For performance sake, my design goals is to keep the generated Users table physical Clustered according to the AppId coulmn not to the PK. On my Initializer class I've tried to manually drop the autogenerated PK clustered index

Can I use Data Annotations to perform a Cascade Delete with Entity Framework 4.1 RC?

不羁的心 提交于 2019-11-28 04:30:24
When using data annotations with EF4.1 RC is there an annotation to cause cascade deletes? public class Category { public int Id { get; set; } [Required] public string Name { get; set; } public ICollection<Product> Products { get; set; } } public class Product { public int Id { get; set; } public string Name { get; set; } public Category Category { get; set; } } Using this model the constraint generated is: ALTER TABLE [Product] ADD CONSTRAINT [Product_Category] FOREIGN KEY ([Category_Id]) REFERENCES [Categorys]([Id]) ON DELETE NO ACTION ON UPDATE NO ACTION; If not how is it achieved? Putting

Entity Framework 4.1 - EFTracingProvider

断了今生、忘了曾经 提交于 2019-11-28 04:26:02
Is there a way to make the EFTracing provider work with EF 4.1? EFTracing seems to need an objectcontext and I use dbcontext. Thanks in advance! Yes, you can. I'm using the community version with both database-first DbContexts and code-first DbContexts. This answer is based on a discussion thread on the project site. For database-first/designer DbContexts (via ADO.NET DbContext Generator templates ), you can simply add the following constructor: public abstract class MyDbContext : DbContext { protected MyDbContext(string nameOrConnectionString) : base(EFTracingProviderUtils

Entity Framework Code First - Why can't I update complex properties this way?

坚强是说给别人听的谎言 提交于 2019-11-28 04:22:57
I'm working on a small sample project using Entity Framework 4.1 (code first). My classes look like this: public class Context : DbContext { public IDbSet<Person> People { get; set; } public IDbSet<EmployeeType> EmployeeTypes { get; set; } } public class Person { [Key] public int Key { get; set; } public string FirstName { get; set; } public string LastName { get; set; } virtual public EmployeeType EmployeeType { get; set; } } public class EmployeeType { [Key] public int Key { get; set; } public string Text { get; set; } virtual public ICollection<Person> People { get; set; } } I've saved a

Eager loading in EntityFramework with DbContext.Database.SqlQuery

大憨熊 提交于 2019-11-28 03:31:53
问题 In EF 4, can I do eager loading of navigation properties by writing sql on DbContext.Database.SqlQuery or DbContext.Set<T>().SqlQuery ? I don't seem to be getting my navigation properties populated. Edit It seems I can do eagerloading with DbContext.Set().SqlQuery, just not DbContext.Database.SqlQuery. Any idea why? 回答1: DbSet.SqlQuery works differently than Database.SqlQuery. The method on DbSet applies to the given entity set. It has to return entities of the given type and by default the

EF 4.1 Code First - OnModelCreating call time

扶醉桌前 提交于 2019-11-28 03:24:24
问题 When I debug my application this method seems not to be executing in constructor context of DbContext. So when it is called then? 回答1: This method is called when EF needs to access database for the first time (so it is not during context instancing). If the database doesn't exists it uses information from compiled model to create it. The model is created only once per application (it is cached internally) so even if you dispose the context your model will be still reused for the next instance

Entity Framework Code First - Defining Relationships/Keys

◇◆丶佛笑我妖孽 提交于 2019-11-28 03:20:19
I am designing my database using code first and I need a little help I think. I am getting this error: Introducing FOREIGN KEY constraint 'SalesOrder_Invoices' on table 'Invoices' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints. Could not create constraint. See previous errors. I am trying to have the following relationships/keys: --> = 1 to Many Relationship Customer --> CustomerLocation CustomerLocation --> SalesOrder SalesOrder --> Invoice SalesRep --> SalesOrder PaymentTerm --> Customer PaymentTerm -->

How to delete a record with a foreign key constraint?

為{幸葍}努か 提交于 2019-11-28 03:14:23
问题 Started a new ASP.NET MVC 3 application and getting the following error: The primary key value cannot be deleted because references to this key still exist. How to solve this? Models (EF code-first) public class Journal { public int JournalId { get; set; } public string Name { get; set; } public virtual List<JournalEntry> JournalEntries { get; set; } } public class JournalEntry { public int JournalEntryId { get; set; } public int JournalId { get; set; } public string Text { get; set; } }

Entity Framework Object Context per request in ASP.NET? [closed]

拥有回忆 提交于 2019-11-28 02:04:27
问题 Is it considered a good practice to use a single ObjectContext per request? I read these objects should be short lived and are not extremely costly to instantiate but does this make the case appealing for one of them per request? If yes, are there any patterns that properly implement this? 回答1: Yes it is an accepted approach to have ObjectContext/DbContext with lifetimes per HttpRequest. Here's a sample I have provided in another answer. Hoewever, it's better to leave these lifetime