Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Los objetos LINQ to SQL siempre participan en algún estado. Por ejemplo, cuando LINQ to SQL crea un nuevo objeto, el objeto está en Unchanged estado. Un nuevo objeto que tú mismo creas es desconocido para DataContext y está en estado Untracked. Después de la ejecución correcta de SubmitChanges, todos los objetos conocidos como LINQ to SQL están en Unchanged estado. (La única excepción son los objetos que se han eliminado correctamente de la base de datos, que están en estado Deleted y no se pueden utilizar en esa instancia de DataContext.)
Estados de objeto
En la tabla siguiente se enumeran los posibles estados para los objetos LINQ to SQL.
| Estado | Descripción |
|---|---|
Untracked |
LinQ to SQL no realiza un seguimiento de un objeto. Entre los ejemplos se incluyen los siguientes: Un objeto no consultado a través del actual DataContext (como un objeto recién creado). : un objeto creado a través de la deserialización - Un objeto consultado a través de un DataContext diferente. |
Unchanged |
Objeto recuperado mediante el uso del actual DataContext y que no se sabe si se ha modificado desde su creación. |
PossiblyModified |
Objeto que está asociado a un DataContextobjeto . Para obtener más información, vea Operaciones de recuperación de datos y CUD en aplicaciones de N niveles (LINQ to SQL). |
ToBeInserted |
Objeto no recuperado utilizando el DataContext actual. Esto produce una operación INSERT en la base de datos durante la ejecución de SubmitChanges. |
ToBeUpdated |
Objeto que se sabe que se ha modificado desde que se recuperó. Esto produce una operación UPDATE en la base de datos durante la ejecución de SubmitChanges. |
ToBeDeleted |
Objeto marcado para su eliminación, lo que provoca una base de datos DELETE durante SubmitChanges. |
Deleted |
Objeto que se ha eliminado en la base de datos. Este estado es final y no permite transiciones adicionales. |
Insertar objetos
Puede solicitar Inserts explícitamente mediante InsertOnSubmit. Como alternativa, LINQ to SQL puede deducir Inserts mediante la búsqueda de objetos conectados a uno de los objetos conocidos que se deben actualizar. Por ejemplo, si agrega un Untracked objeto a un EntitySet<TEntity> objeto o establece un EntityRef<TEntity> en un Untracked objeto, hace que el objeto Untracked sea accesible a través de los objetos rastreados en el gráfico. Al procesar SubmitChanges, LINQ to SQL recorre los objetos que están siendo rastreados y detecta cualquier objeto persistente accesible que no esté rastreado. Estos objetos son candidatos para la inserción en la base de datos.
En el caso de las clases de una jerarquía de herencia, InsertOnSubmit(o) también establece el valor del miembro designado como discriminador para que coincida con el tipo del objeto o. Si un tipo que coincide con el valor de discriminador predeterminado, esta acción hace que dicho valor se sobrescriba con el valor predeterminado. Para obtener más información, consulte Soporte de herencia.
Importante
Un objeto agregado a un Table no está en la caché de identidades. La caché de identidades solo refleja lo que se recupera de la base de datos. Después de una llamada a InsertOnSubmit, la entidad agregada no aparece en las consultas contra la base de datos hasta que SubmitChanges se haya completado correctamente.
Eliminación de objetos
Un objeto o del que se realiza un seguimiento se marca para la eliminación mediante una llamada a DeleteOnSubmit en el objeto Table<TEntity> adecuado. LINQ to SQL considera la eliminación de un objeto de un EntitySet<TEntity> como una operación de actualización, y el valor de clave externa correspondiente se establece en null. El destino de la operación (o) no se elimina de su tabla. Por ejemplo, cust.Orders.DeleteOnSubmit(ord) indica una actualización en la que la relación entre cust y ord se rompe estableciendo la clave externa ord.CustomerID en null. No provoca la eliminación de la fila correspondiente a ord.
LINQ to SQL realiza el siguiente procesamiento cuando se elimina un objeto (DeleteOnSubmit) de su tabla:
Cuando se llama a SubmitChanges, se realiza una operación de
DELETEpara ese objeto.La eliminación no se propaga a los objetos relacionados, estén cargados o no. En concreto, los objetos relacionados no se cargan para actualizar la propiedad de relación.
Después de la ejecución exitosa de SubmitChanges, los objetos se establecen en el estado de
Deleted. Como resultado, no se puede usar el objeto ni suiden ese DataContext. La caché interna mantenida por una DataContext instancia no elimina los objetos recuperados o agregados como nuevos, incluso después de que los objetos se hayan eliminado en la base de datos.
Solo se puede llamar a DeleteOnSubmit en un objeto del que DataContext realiza un seguimiento. Para un Untracked objeto, debe llamar a Attach antes de llamar a DeleteOnSubmit. La llamada a DeleteOnSubmit en un Untracked objeto produce una excepción.
Nota:
Al quitar un objeto de una tabla se indica a LINQ to SQL que genere un comando SQL DELETE correspondiente en el momento de SubmitChanges. Esta acción no quita el objeto de la memoria caché ni propaga la eliminación a objetos relacionados.
Para reclamar el id de un objeto eliminado, use una nueva DataContext instancia. Para la limpieza de objetos relacionados, puede usar la característica de eliminación en cascada de la base de datos o eliminar manualmente los objetos relacionados.
Los objetos relacionados no tienen que eliminarse en ningún orden especial (a diferencia de en la base de datos).
Actualizar objetos
Puede detectar Updates mediante la observación de notificaciones de cambios. Las notificaciones se proporcionan a través del evento PropertyChanging en los establecedores de propiedades. Cuando se notifica a LINQ to SQL el primer cambio a un objeto, crea una copia del objeto y considera que el objeto es candidato para generar una Update instrucción.
Para los objetos que no implementan INotifyPropertyChanging, LINQ to SQL mantiene una copia de los valores que tenían los objetos cuando se materializaron por primera vez. Cuando llamas a SubmitChanges, LINQ to SQL compara los valores actuales y originales para decidir si el objeto ha sido modificado.
Para las actualizaciones de relaciones, la autoridad es la referencia del elemento secundario al elemento primario (es decir, la referencia que corresponde a la clave externa). La referencia en la dirección inversa (es decir, de padre a hijo) es opcional. Las clases de relación (EntitySet<TEntity> y EntityRef<TEntity>) garantizan que las referencias bidireccionales sean coherentes para las relaciones uno a varios y uno a uno. Si el modelo de objetos no usa EntitySet<TEntity> o EntityRef<TEntity>, y si la referencia inversa está presente, es su responsabilidad mantenerla coherente con la referencia hacia delante cuando se actualiza la relación.
Si actualiza la referencia requerida y la clave externa correspondiente, debe asegurarse de que coinciden. Si los dos no están sincronizados en el momento en que se llama a InvalidOperationException, se lanzará una SubmitChanges excepción. Aunque los cambios de los valores de clave externa son suficientes para que se actualice la fila subyacente, debería cambiar la referencia para mantener la conectividad del gráfico de objetos y la coherencia bidireccional de las relaciones.