Design Meeting Notes - July 26, 2012
- Should we move all public async methods to a separate namespace as extension methods so they don’t pollute Intellisense?
- We will leave async methods in S.D.E. primarily to reduce the number of namespaces that people will need to import.
- Async versions of methods that LINQ to Entities does not support will be removed.
- Should we remove the Create methods from IDbAsyncQueryProvider and derive it from IQueryProvider?
- I changed Database.SqlQuery to return DbSqlQuery so that it could be enumerated asynchronously (without tracking) and DbSet.SqlQuery will now return DbSqlSetQuery that derives from DbSqlQuery.
- Is this the right hierarchy and naming?
- Should we provide singleton async methods on DbSqlQuery, since it doesn’t implement IQueryable?
- We should not change the name of the existing class—unnecessary breaking change.
- We need to find a name for the new class—probably will be done as part of polishing later
- We should add instance async methods in the same way that we did for AsNoTracking
- Async feedback
- Current draft looks good; don’t need to list out all API
- General goals/format
- The one-pager should remain very high level and provide a short overview of the important points about the feature.
- The audience is the community who wants an overview of the current state of the feature.
- The format and sections are not rigidly defined and should reflect the important things the community would need to know. For example, it might include:
- API Usage
- The document should be periodically updated as development progresses.
- It will form the basis of a blog post when the feature is implemented to the level that we want to illicit wider feedback from the community.
- Note that this is not an up-front design document or a comprehensive spec. It’s just a summary of where we are at with the design.
A potential contributor has started a discussion about adding a new initializer to our lineup. The initializer would be used when you don’t ever want EF to create a database (even if it doesn’t exist) but do what EF to do a check that the database exists
and that the model matches and throw if not. This allows for a fail-fast in al cases where the database is not up-to-date. It should probably also fail if model information cannot be found in the database.
- This seems like a useful initializer but should it go into EF.dll or is it better off in contrib or elsewhere?
- Decision: The idea has merit for the core; i.e. we are interested.
- Should it also fail if model information cannot be found?
- Decision: Yes; it’s primary a fail fast checker for people using Migrations.
- Related: The IoC work requires a NullDatabaseInitializer for disabling database initialization (since null means something else). Should this be public?
- Decision: Yes, it can be made public.