¿Qué efecto tienen los diferentes EF 4 SaveOptions en el ObjectContext?

que estoy tratando de resolver un error muy similar al que se describe aquí:¿Qué efecto tienen los diferentes EF 4 SaveOptions en el ObjectContext?

InvalidOperationException when calling SaveChanges in .NET Entity framework

Parece que la solución (que no he probado todavía, es cierto) es pasar System.Data.Objects .SaveOptions.None como el parámetro SaveOptions para el método SaveChanges().

Así que antes de hacerlo, trato de entender exactamente cómo funcionan las diferentes SaveOptions (Ninguna, AcceptAllChangesAfterSave, DetectAllChanges). Sin embargo, no he podido encontrar una explicación clara de esto, ni estoy seguro de cuál es el valor predeterminado. ¿Alguien puede aclarar?

Gracias!

ACTUALIZACIÓN: He publicado la pregunta problema real aquí: System.InvalidOperationException when trying to iteratively add objects using EF 4

Fuente

2011-01-12 morganpdx

Buena pregunta (1).

En pocas palabras (por lo que entiendo):

SaveOptions.DetectChangesBeforeSave: este es el valor predeterminado. Cuando lo haga ObjectContext.SaveChanges(), se llama al método DetectChanges() a las entidades de conexión sincronizada en el OSM.

SaveOptions.AcceptAllChangesAfterSave: Al hacer ObjectContext.SaveChanges(), el método AcceptAllChanges() se llama - que es la tripa de la OSM, en el que se repitan ciertos las entidades en el gráfico, direcciones y establecen en Sin cambios/Villa.

SaveOptions.None: cuando lo hace ObjectContext.SaveChanges(), los cambios se guardan de forma inmediata - sin sincronización en absoluto. Lo que está en el gráfico es lo que se guardará.

En mi experiencia, no me he equivocado con esto, lo dejé como predeterminado (DetectChangesBeforeSave).

A veces con POCO he escuchado que necesita llamar explícitamente al DetectChanges, pero nunca he visto una recomendación/solución para cambiar las SaveOptions a ninguna.

¿Estás seguro de que la solución en esa pregunta es establecer SaveOptions en ninguno? Tal vez deberías proporcionar detalles (o hacer una pregunta separada) sobre el error que recibes, ya que un cambio como este afectará a toda tu capa de persistencia.

Fuente

2011-01-12 22:35:42 RPM1984

Gracias - exactamente mi razón para hacer la pregunta, ya que afectará a toda mi aplicación para solucionar solo este problema. Soy bastante reacio a hacer eso con una solución que no entiendo del todo. ¿A qué te refieres cuando dices OSM? EDITAR: ObjectStateManager. Lo tengo. :) – morganpdx

Y sí, debería publicar una pregunta, ya que esta es la única solución establecida en el otro problema que dice que funcionará en mi caso. Pero parece ser exactamente el mismo problema. – morganpdx

@morganpdx: ¿cómo se configura EF? ¿está utilizando la generación de código predeterminada o está utilizando POCO? Y si es así, ¿está utilizando algún seguimiento de cambios (por ejemplo, entidades de seguimiento automático, objetos proxy, etc.)? Publique una pregunta con esta información y el error/escenario/problema que está teniendo. – RPM1984

corrección de corto para

SaveOptions.DetectChangesBeforeSave: este es el valor predeterminado. Cuando hace ObjectContext.SaveChanges(), el método DetectChanges() se llama a entidades de conexión sincronizada en el OSM.

SaveChanges es una versión sobrecargada de SaveChanges(SaveOptions optsions) método, en esta versión sin parámetros llama a esto

SaveChanges(SaveOptions.DetectChangesBeforeSave | SaveOptions.AcceptAllChangesAfterSave)

SaveOptions es una enumeración de la bandera y para concluir, SaveOptions.DetectChangesBeforeSave | SaveOptions.AcceptAllChangesAfterSave es el valor predeterminado de SaveChanges() no la DetectChangesBeforeSave

Fuente

2011-11-08 21:42:03 D3M80L

¿Qué efecto tienen los diferentes EF 4 SaveOptions en el ObjectContext?

Respuesta

Cuestiones relacionadas