Design Meeting Notes - July 26, 2012

Async

• Should we move all public async methods to a separate namespace as extension methods so they don’t pollute Intellisense?
  • Decisions:
    • 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?
  • Decision: Yes
• 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?
  • Decisions:
    • 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

One-pagers

• 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:
    • Goals
    • Non-goals
    • Dependencies
    • Design
    • API Usage
    • Challenges
    • Limitations
  • 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.

Initializer proposal

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.

Two questions:

• 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.