James D. Schwarzmeier

My feedback

  1. 153 votes
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    James D. Schwarzmeier supported this idea  · 
    James D. Schwarzmeier commented  · 

    I agree fully. There are a number of ideas out there very similar to this:

    http://data.uservoice.com/forums/72025-ado-net-entity-framework-ef-feature-suggestions/suggestions/1935605-addobject-or-attach-should-not-add-or-attach-whole

    http://data.uservoice.com/forums/72025-ado-net-entity-framework-ef-feature-suggestions/suggestions/2435952-support-a-removeall-command-that-does-not-require-

    I'm sure there are others too. These all point to a basic need: the ability to leverage the O/R mapping (i.e. SQL generation) capabilities of EF, but bypass the whole change tracking mechanism. It seems to me that there are seven basic things we need to be able to do...there might be more:

    - Insert new rows
    - Update row for a specific entity
    - Update rows matching a WHERE clause (via LINQ, etc.)
    - Delete row for a specific entity
    - Delete rows matching a WHERE clause (again view LINQ or something)
    - Associate entities in a many-to-many relationship
    - Remove the association between entities in a many-to-many relationship

    Ideally we could essentially build up a series of commands, and then have EF flush all commands out to the DB all at once -- but the key being that the application developer assumes responsibility for knowing what changes need to occur and in what order. Hopefully it would support objects using either foreign key properties OR navigation properties.

    This would be especially helpful in some types of disconnected n-tier applications.

  2. 192 votes
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    James D. Schwarzmeier supported this idea  · 

Feedback and Knowledge Base