Not all our EF tests are included in the OSS code base - we need to review the tests we have and port some of them or implement new tests to cover the product.
Edited Issue: Port EF5 Checkin Test Coverage to OSS Code Base [411]
↧
↧
New Post: Database documents
Hi,
Is there any plan to import tables and fields descriptions as code document (XML) and update database descriptions after changes on database first or model first?
Or when we set XML documents on code first, create/update database descriptions?
Thanks
↧
Created Issue: Allow for NoTracking Context or DbSet [601]
It would be great to have a broader way to define no tracking contexts or no tracking DbSets so that we can design read-only models or DbSets. Yes we can control that in a repository but controlling it at the context or DbSEt level would be simpler for devs to implement read-only data. It could also alleviate the problem of accidentally tracking data because you've set a navigation property. My pref would be to see this for a context. It would let you query but nothing else. Not sure how this will effect relationships via eager, lazy or explicit loading.
↧
Commented Issue: Allow for NoTracking Context or DbSet [601]
It would be great to have a broader way to define no tracking contexts or no tracking DbSets so that we can design read-only models or DbSets. Yes we can control that in a repository but controlling it at the context or DbSEt level would be simpler for devs to implement read-only data. It could also alleviate the problem of accidentally tracking data because you've set a navigation property. My pref would be to see this for a context. It would let you query but nothing else. Not sure how this will effect relationships via eager, lazy or explicit loading.
Comments: Two main data types could be added to the Entity Framework API; ReadOnlyDbSet<T> and ReadOnlyDbContext; We could already create a read-only repository to achieve this goal; But this would make it much more strict to define the read-only DbSets within the DbContext.
Comments: Two main data types could be added to the Entity Framework API; ReadOnlyDbSet<T> and ReadOnlyDbContext; We could already create a read-only repository to achieve this goal; But this would make it much more strict to define the read-only DbSets within the DbContext.
↧
Commented Issue: Allow for NoTracking Context or DbSet [601]
It would be great to have a broader way to define no tracking contexts or no tracking DbSets so that we can design read-only models or DbSets. Yes we can control that in a repository but controlling it at the context or DbSEt level would be simpler for devs to implement read-only data. It could also alleviate the problem of accidentally tracking data because you've set a navigation property. My pref would be to see this for a context. It would let you query but nothing else. Not sure how this will effect relationships via eager, lazy or explicit loading.
Comments: Sounds Great! It would be really great to have such feature at DbSet level. I am excited to see what can be done for that. Thanks Julie.
Comments: Sounds Great! It would be really great to have such feature at DbSet level. I am excited to see what can be done for that. Thanks Julie.
↧
↧
New Post: Using EF5 - Schema Mapping and Namespaces problem
I found your question on stackoveflow and answered it there: http://stackoverflow.com/questions/12978163/entity-schema-mapping-and-namespaces/12980965#12980965
↧
New Comment on "Roadmap"
When can we expect Table Valued Functions in Code First? How about Scalar Functions?
↧
Created Issue: Update-Database uses generated Configuration, while F5->Migrate does not. [602]
It's a small inconsistency which left me wondering why my seed data was sometimes showing up and sometimes not (depending on whether I had run 'Update-Database' prior to pressing F5).
Prerequisite: A new Code First model (no database yet) and main method which prints out data (so you can see if there is any).
Repro:
1. Enable-Migrations -EnableAutomaticMigrations
2. Add seed data in generated Configuration.Seed() method.
3. Press 'F5'
Expected:
Seed data shows up. (Configuration is used by F5)
Actual:
Seed data does not show up.
Workaround:
Run 'Update-Database' before pressing F5.
Prerequisite: A new Code First model (no database yet) and main method which prints out data (so you can see if there is any).
Repro:
1. Enable-Migrations -EnableAutomaticMigrations
2. Add seed data in generated Configuration.Seed() method.
3. Press 'F5'
Expected:
Seed data shows up. (Configuration is used by F5)
Actual:
Seed data does not show up.
Workaround:
Run 'Update-Database' before pressing F5.
↧
Commented Feature: Designer: Better navigation property names when multiple relationships to the same table [125]
When multiple relationships to the same table are present the navigation properties are just postfixed with a name. We could consider using the FK name or some other means to make it clearer which is which.
This item was migrated from the DevDiv work item tracking system [ID=6053].
This work item originated from connect.microsoft.com. A member of the EF team at Microsoft should close the related Connect issue when closing this work item.
Comments: you can use nhibernate for .net for more clear naming. but i want EF to become more powerful too.
This item was migrated from the DevDiv work item tracking system [ID=6053].
This work item originated from connect.microsoft.com. A member of the EF team at Microsoft should close the related Connect issue when closing this work item.
Comments: you can use nhibernate for .net for more clear naming. but i want EF to become more powerful too.
↧
↧
New Post: FxCop Suppressions For Designer Generated Code?
When using EF to create a model for a database, the out-of-the-box generated code generates a number of FxCop warnings. For now I've worked around them by adding suppressions to the .tt templates in my project, but ideally the generated code would be clean to start with.
Creating a simple model against the SQL 2012 AdventureWorks database generates the following warnings:
- CA1506: Warning for excessive class-coupling due to the fact there's a class referenced for each table in the database due to the one-to-one relationship of tables to types.
- CA2214: Warning for using virtual members in the constructor of each model where it contains at least one navigation property.
- CA2227: Warning for each navigation property as it is a collection property with a getter and a setter.
EF 5.0 generates some other warnings (CA1063), but these don't appear to be issues in EF 6.0.
I've submitted a pull request to suppress these messages, but it's been suggested that these may wish to be fixed instead by changing the generated code. Personally I think they should be suppressed as they appear to be design decisions made to improve testability or are inherent to the EF approach to database modelling. My reasoning for each is as below.
CA1506 should be suppressed, as if you're working with a genuinely large database (50+) tables, then it would be overkill to pull the context apart into different context classes, as you'd end up with a fair amount of duplicate code, and may end up having to use more than one context to perform operations between them, which would probably cause a lot of headaches.
CA2214 is fired due to the navigation properties being virtual. I'm guessing they were made virtual to allow tools like Moq to use setups on the navigation properties for use in unit tests. If this is the reason why they are designed as such, it would seem to be safe to suppress the warning on the grounds that someone is unlikely to derive a class from a model type and override the properties manually in such a way that caused undesirable behaviour.
CA2227 is fired as the navigation properties are of type ICollection<T>, which causes FxCop to suggest that instead they should have a private setter to prevent them being set by public callers. Again, the current design appears to be sensible to that the navigation properties can be easily accessed for setup in unit tests, otherwise you'd need to perform constructs such as:
Model foo = new Model(); foo.NavProperty.Clear(); foreach (var item in myMockCollection) { foo.NavProperty.Add(item); }
which is much more verbose that the current usage of:
Model foo = new Model();
foo.NavProperty = myMockCollection;
Based on the above, personally I think these three warnings should be suppressed so that the models that are generated are FxCop clean.
Any other thoughts on whether they should be suppressed or the design changed instead to eliminate the warnings in the first place?
Martin
↧
Created Issue: Possible unnecessary code in ViewGenerator [603]
While adding optimizarions to view generation (ToListOrNotToListTwo) we detected a variable that was ever only assigned the result of GetViewsForExtentAndType(). We removed the assignment but we did not remove the call since we did not know if GetViewsForExtentAndType is a pure method. If we can confirm that the method doesn't have necessary side-effects we should remove the call as well. This is an area that is very perf sensitive and something like this can help a lot.
↧
Edited Issue: Possible unnecessary code in ViewGenerator.cs [603]
While adding optimizarions to view generation (ToListOrNotToListTwo) we detected a variable that was ever only assigned the result of GetViewsForExtentAndType(). We removed the assignment but we did not remove the call since we did not know if GetViewsForExtentAndType is a pure method. If we can confirm that the method doesn't have necessary side-effects we should remove the call as well.
This is in general an area that is very performance sensitive and something like this can help a lot.
This is in general an area that is very performance sensitive and something like this can help a lot.
↧
Closed Issue: Possible unnecessary code in ViewGenerator.cs [603]
While adding optimizarions to view generation (ToListOrNotToListTwo) we detected a variable that was ever only assigned the result of GetViewsForExtentAndType(). We removed the assignment but we did not remove the call since we did not know if GetViewsForExtentAndType is a pure method. If we can confirm that the method doesn't have necessary side-effects we should remove the call as well.
This is in general an area that is very performance sensitive and something like this can help a lot.
Comments: Closing as this is the method that actually generates the views for a type. They are added to the views collecting parameter.
This is in general an area that is very performance sensitive and something like this can help a lot.
Comments: Closing as this is the method that actually generates the views for a type. They are added to the views collecting parameter.
↧
↧
Edited Issue: Consider programatically granting SQL Express service account file system access to test directory [378]
Tests that use AttachDBFileName connection strings can cause access denied errors unless the account used by SQL Express has enough file system rights on the directory where databases are created or modified. This can be the case if for instance the test directory is created under the user profile. Workaround is to manually grant access, e.g.:
icacls test /grant "Authenticated Users":RWMD /inheritance:e
icacls test /grant "Authenticated Users":RWMD /inheritance:e
↧
Source code checked in, #b3e62869e736
Final CR changes for VG optimization.
↧
Commented Issue: Possible unnecessary code in ViewGenerator.cs [603]
While adding optimizarions to view generation (ToListOrNotToListTwo) we detected a variable that was ever only assigned the result of GetViewsForExtentAndType(). We removed the assignment but we did not remove the call since we did not know if GetViewsForExtentAndType is a pure method. If we can confirm that the method doesn't have necessary side-effects we should remove the call as well.
This is in general an area that is very performance sensitive and something like this can help a lot.
Comments: Thanks for looking!
This is in general an area that is very performance sensitive and something like this can help a lot.
Comments: Thanks for looking!
↧
Created Issue: HasColumnName is ignored for Complex Type [604]
I attempted to introduce a Complex Type ContactDetail for my Client class. I added column names mapping through ClientMap.cs file. However, in run-time wrong SQL is generated using convention rather than the name I specified in the mapping file.
I have the whole case documented in this thread http://social.msdn.microsoft.com/Forums/en-US/transactsql/thread/6a9cc309-5767-4db4-a039-fb7f17d13821
I have the whole case documented in this thread http://social.msdn.microsoft.com/Forums/en-US/transactsql/thread/6a9cc309-5767-4db4-a039-fb7f17d13821
↧
↧
New Post: add-migration with the new multi context feature
Hey guys, still working on getting company approval for this.. should happen just takes time in a company of 100k people.
Eric Hexter
blog | http://Hex.LosTechies.com
info | http://www.linkedin.com/in/erichexter
Eric Hexter
blog | http://Hex.LosTechies.com
info | http://www.linkedin.com/in/erichexter
On Fri, Oct 5, 2012 at 11:46 AM, AndrewPeters <notifications@codeplex.com> wrote:
From: AndrewPeters
Eric,
We are absolutely looking for contributions. UpForGrabs is something we would take but don't currently have the bandwidth to do ourselves. Any tooling improvements would be greatly appreciated!
Thanks,
Andrew.
Read the full discussion online.
To add a post to this discussion, reply to this email (entityframework@discussions.codeplex.com)
To start a new discussion for this project, email entityframework@discussions.codeplex.com
You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.
Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com
↧
Commented Issue: Code First: Allow subclasses to map field to same database column with TPH inheritance [583]
When using TPH inheritance, Code First requires every field defined in a subclass to be mapped to a unique database column. However, there are scenarios where it would be simpler for subclasses to map fields to the same column. For example:
public abstract class Vehicle { ... }
public class Car : Vehicle { ... }
public class Truck : Vehicle { ... }
public class Trike : Vehicle { public string WheelOrientation { get; set; } ... }
public class CanAmSpyder : Vehicle { public string WheelOrientation { get; set; } ... }
Given the above example with Code First TPH, the database table "Vehicle" would require two columns for wheel orientation: "TrikeWheelOrientation" and "CanAmSpyderWheelOrientation". But having a single "WheelOrientation" column that both the Trike subclass and CanAmSpyder subclass can map to seems cleaner.
Comments: Additional information: Code First produces correct mapping for this model, but tries to introduce two columns with the same name in the storage model (which explains the exception). Repro: public class Person { public int Id { get; set; } public string Name { get; set; } } public class Student : Person { public string Career { get; set; } } public class Teacher : Person { public string Department { get; set; } } class Program { static void Main(string[] args) { var modelBuilder = new DbModelBuilder(); modelBuilder.Entity<Person>(); modelBuilder.Entity<Teacher>().Property(p => p.Department).HasColumnName("Data"); modelBuilder.Entity<Student>().Property(p => p.Career).HasColumnName("Data"); EdmxWriter.WriteEdmx(modelBuilder.Build( new DbProviderInfo("System.Data.SqlClient", "2008")), XmlTextWriter.Create(Console.Out, new XmlWriterSettings() { Indent = true })); } } Output: … <StorageModels> <Schema Namespace="CodeFirstDatabaseSchema" Provider="System.Data.SqlClient" ProviderManifestToken="2008" Alias="Self" xmlns="http://schemas.microsoft.com/ado/2009/11/edm/ssdl"> <EntityType Name="Person"> <Key> <PropertyRef Name="Id" /> </Key> <Property Name="Id" Type="int" StoreGeneratedPattern="Identity" Nullable="false" /> <Property Name="Name" Type="nvarchar(max)" Nullable="true" /> <Property Name="Data" Type="nvarchar(max)" Nullable="true" /> <Property Name="Data" Type="nvarchar(max)" Nullable="true" /> <Property Name="Discriminator" Type="nvarchar" MaxLength="128" Nullable="false" /> </EntityType> <EntityContainer Name="CodeFirstDatabase"> <EntitySet Name="Person" EntityType="Self.Person" Schema="dbo" Table="People" /> </EntityContainer> </Schema> </StorageModels> …
public abstract class Vehicle { ... }
public class Car : Vehicle { ... }
public class Truck : Vehicle { ... }
public class Trike : Vehicle { public string WheelOrientation { get; set; } ... }
public class CanAmSpyder : Vehicle { public string WheelOrientation { get; set; } ... }
Given the above example with Code First TPH, the database table "Vehicle" would require two columns for wheel orientation: "TrikeWheelOrientation" and "CanAmSpyderWheelOrientation". But having a single "WheelOrientation" column that both the Trike subclass and CanAmSpyder subclass can map to seems cleaner.
Comments: Additional information: Code First produces correct mapping for this model, but tries to introduce two columns with the same name in the storage model (which explains the exception). Repro: public class Person { public int Id { get; set; } public string Name { get; set; } } public class Student : Person { public string Career { get; set; } } public class Teacher : Person { public string Department { get; set; } } class Program { static void Main(string[] args) { var modelBuilder = new DbModelBuilder(); modelBuilder.Entity<Person>(); modelBuilder.Entity<Teacher>().Property(p => p.Department).HasColumnName("Data"); modelBuilder.Entity<Student>().Property(p => p.Career).HasColumnName("Data"); EdmxWriter.WriteEdmx(modelBuilder.Build( new DbProviderInfo("System.Data.SqlClient", "2008")), XmlTextWriter.Create(Console.Out, new XmlWriterSettings() { Indent = true })); } } Output: … <StorageModels> <Schema Namespace="CodeFirstDatabaseSchema" Provider="System.Data.SqlClient" ProviderManifestToken="2008" Alias="Self" xmlns="http://schemas.microsoft.com/ado/2009/11/edm/ssdl"> <EntityType Name="Person"> <Key> <PropertyRef Name="Id" /> </Key> <Property Name="Id" Type="int" StoreGeneratedPattern="Identity" Nullable="false" /> <Property Name="Name" Type="nvarchar(max)" Nullable="true" /> <Property Name="Data" Type="nvarchar(max)" Nullable="true" /> <Property Name="Data" Type="nvarchar(max)" Nullable="true" /> <Property Name="Discriminator" Type="nvarchar" MaxLength="128" Nullable="false" /> </EntityType> <EntityContainer Name="CodeFirstDatabase"> <EntitySet Name="Person" EntityType="Self.Person" Schema="dbo" Table="People" /> </EntityContainer> </Schema> </StorageModels> …
↧
Created Issue: Possibility to have generate views also [605]
It would be nice to EF be able to define a View and not only tables.
To do that, right now I have a table and will be droped in the Seed method of the configuration and a view with the same name will be created.
context.Database.ExecuteSqlCommand("IF EXISTS (SELECT * FROM sys.tables WHERE object_id = OBJECT_ID(N'[dbo].[vwUserTypes]')) DROP TABLE [dbo].[vwUserTypes]");
context.Database.ExecuteSqlCommand(@"CREATE VIEW [dbo].[vwUserTypes] AS SELECT TOP (100) PERCENT ReferenceId AS UserTypeId, ReferenceValue AS UserType FROM dbo.tblSystemReferences WHERE (ReferenceTable = 'UserType') AND (IsActive = 1) ORDER BY UserTypeID");
Doing this will work fine but if I want to create a relation between this view and tblUser table the system said that cannot create the FK in the view.
What I expect it's possible to mark my domain object to be serializes as a view and somewhere and somehow I could create a linq query to define my view or even SQL Statement like I do now in my example.
In the end, if I want to link a object to this View, the EF will not create a FK in the View.
is the future, base on a method would be nice to generate the store procedure code too ... but that's another story.
Regards
Paulo Aboim Pinto
Odivelas - Portugal
To do that, right now I have a table and will be droped in the Seed method of the configuration and a view with the same name will be created.
context.Database.ExecuteSqlCommand("IF EXISTS (SELECT * FROM sys.tables WHERE object_id = OBJECT_ID(N'[dbo].[vwUserTypes]')) DROP TABLE [dbo].[vwUserTypes]");
context.Database.ExecuteSqlCommand(@"CREATE VIEW [dbo].[vwUserTypes] AS SELECT TOP (100) PERCENT ReferenceId AS UserTypeId, ReferenceValue AS UserType FROM dbo.tblSystemReferences WHERE (ReferenceTable = 'UserType') AND (IsActive = 1) ORDER BY UserTypeID");
Doing this will work fine but if I want to create a relation between this view and tblUser table the system said that cannot create the FK in the view.
What I expect it's possible to mark my domain object to be serializes as a view and somewhere and somehow I could create a linq query to define my view or even SQL Statement like I do now in my example.
In the end, if I want to link a object to this View, the EF will not create a FK in the View.
is the future, base on a method would be nice to generate the store procedure code too ... but that's another story.
Regards
Paulo Aboim Pinto
Odivelas - Portugal
↧
More Pages to Explore .....
