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


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

Last edited Dec 14, 2012 at 5:22 PM by ajcvickers, version 3


No comments yet.