(Actualización () se actualiza, si no hay una clave principal, se informará un error.
saveOrUpdate() guarda o actualiza, realiza la inserción sin clave principal.
Actualización: es una operación de actualización para objetos transitorios (transient) o simplemente desconectados (separados). La operación de actualización para objetos transitorios generalmente no tiene ningún efecto para los objetos desconectados, se realiza una operación de sincronización, es decir, los datos de la base de datos cambian. Y el estado del objeto también se convierte en un objeto gestionado.
SaveOrUpdate: También opera en operaciones transitorias o desconectadas. En cuanto a si insertar o actualizar, debe analizarse de acuerdo con algunas condiciones específicas especificadas en la identificación. Sin embargo, personalmente creo que cuando es obvio que solo ocurrirá la operación de inserción, es mejor evitar usar saveOrUpdate y simplemente usar guardar directamente)
Comencemos con algunos conceptos:
En Hibernate, el concepto central es la gestión del estado de PO. Una PO tiene tres estados:
1. VO que no persiste
En este momento, es un objeto de memoria VO y el ciclo de vida lo gestiona la JVM.
2. La PO ha persistido y los datos de la base de datos se asignan en este momento durante el ciclo de vida de la sesión y la base de datos administra el ciclo de vida.
3. Ha persistido, pero ahora se ha desconectado de la sesión. Si ejecuta esta PO que se ha desconectado de la sesión como VO, también puede ingresar a otra sesión y continuar administrando el estado de la PO. , se convierte en un PO. Este tipo de orden de compra en realidad cruza
La sesión realiza el mantenimiento del estado.
En JDO1.x tradicional, PO solo tiene los dos primeros estados. Una vez que un PO se separa del PM, pierde su estado y ya no está asociado con los datos de la base de datos. Se convierte en un VO de memoria pura.
Incluso si agrega un nuevo MP, su estado no se puede restaurar.
La ventaja de Hibernate es que después de que un PO abandona la sesión, aún puede mantener el estado. Después de ingresar a una nueva sesión, la capacidad de administración del estado se restablece.
Debe usar session.update o session.saveOrUpdate, que es lo que menciona la referencia de Hibernate en "requiere una programación ligeramente diferente".
modelo"
Ahora ingrese oficialmente a este tema:
En pocas palabras, actualizar y guardarOrUpdate se utilizan para administrar el estado de las órdenes de compra entre sesiones.
Suponiendo que su PO no necesita cruzar sesiones, entonces no es necesario usarlo. Por ejemplo, si abre una sesión, opera la PO y luego la cierra, no volverá a usar esta PO.
Entonces no es necesario utilizar la actualización.
Así que veamos el ejemplo anterior:
código java
Foo foo=sess.load(Foo.class,id);;
foo.setXXX(xxx);;
sess.flush();;
sess.commit();;
Foo foo=sess.load(Foo.class,id);; foo.setXXX(xxx);; sess.flush();;
Todas las operaciones del objeto PO foo se completan dentro de un ciclo de vida de sesión, por lo que no es necesario realizar explícitamente operaciones como sess.update(foo). Hibernate detectará automáticamente que el objeto foo tiene
ha sido modificado, por lo que se envía un sql de actualización a la base de datos. Por supuesto, no está mal si insistes en agregar sess.update(foo), pero no es necesario hacerlo.
Sesión cruzada significa que después de cerrar la sesión, aún usa este objeto PO como VO. Luego, modifica sus propiedades fuera de la sesión y luego desea abrirlo nuevamente.
Abra una sesión y guarde las modificaciones del atributo VO en la base de datos, luego deberá usar la actualización.
código java
// en la primera sesión
Gato gato = (Gato); primera sesión.carga(Cat.class, catId);;
Potencial de gatoMate = nuevo gato();;
primera sesión. guardar (potencialMate);;
// en un nivel superior de la aplicación
cat.setMate(potencialMate);;
// más tarde, en una nueva sesión
segunda sesión.update(cat);; // actualizar gato
segunda sesión.update(compañero); // actualizar compañero
// en la primera sesión Cat cat = (Cat); firstSession.load(Cat.class, catId);; Cat potencialMate = new Cat();;
firstSession.save(potentialMate);; // en un nivel superior de la aplicación cat.setMate(potentialMate); // más tarde, en un
nueva sesión secondSession.update(cat); // actualizar cat secondSession.update(mate); // actualizar compañero
Los objetos gato y compañero se obtienen en la primera sesión. Una vez cerrada la primera sesión, se convierten en el tercer estado del PO, y el PO que la sesión ha separado.
Su información de estado aún se conserva. Cuando ingresan a la segunda sesión, pueden actualizar el estado inmediatamente. Pero debido a la operación de modificación en cat: cat.setMate
(potentialMate); se realiza fuera de la sesión. Hibernate no puede saber que el objeto cat ha sido modificado. La segunda sesión no conoce esta modificación, por lo que debe ser explícita.
Llame a secondSession.update(cat); para notificar a Hibernate que el objeto cat ha sido modificado y debe enviar el sql de actualización.
Entonces esta es la función de actualización. Solo se escribirá cuando un objeto PO esté sincronizando su estado entre sesiones. Cuando no es necesario procesar un objeto PO en todas las sesiones,
Al realizar la gestión del estado, no es necesario escribir actualizaciones.
Hablemos del uso de saveOrUpdate:
La diferencia entre saveOrUpdate y update radica en la estrategia que adopta Hibernate para PO en la gestión del estado de PO entre sesiones.
Por ejemplo, cuando escribe un DAOImpl, agregue una relación matemática al objeto cat, como se define a continuación:
código java
addMate public void (gato gato, compañero compañero);
Sesión sesión = ...;
Transacción tx = ...;
sesión.actualización(gato);;
cat.addMate(compañero);;
tx.commit();;
sesión.cerrar();;
};
public void addMate(Gato gato, Mate compañero); { Sesión de sesión = ...; Transacton tx = ...;
cat.addMate(compañero);; tx.commit();; sesión.close();;
Obviamente, es necesario encapsular las operaciones de Hibernate en DAO, de modo que los programadores de la capa empresarial y los programadores de la capa web no necesiten conocer Hibernate y llamar directamente a DAO.
En este punto surge el problema: existe un requisito previo necesario para que el código anterior se ejecute correctamente, es decir, el objeto cat del parámetro de llamada al método debe ser un PO que haya persistido, es decir, debería
Primero consúltelo desde la base de datos y luego úselo así. Pero los programadores en la capa empresarial obviamente no conocen este misterio interno si su negocio es agregar un gato de vez en cuando.
Su compañero, obviamente lo llamará así, aparece un nuevo objeto gato y luego agregaMate:
código java
Gato gato = nuevo Gato();;
gato.setXXX();;
daoimpl.addMate(gato,compañero);;
Gato gato = nuevo Gato();; cat.setXXX();; daoimpl.addMate(gato, compañero);;
Pero tenga en cuenta que este objeto cat es solo un VO, no ha persistido, no es un PO y no está calificado para llamar al método addMate, por lo que llamar al método addMate en realidad no irá a
Para enviar SQL actualizado en la base de datos, el objeto cat debe guardarse primero en la base de datos. Solo después de que realmente se convierta en un PO podrá calificarse para addMate.
Tienes que hacerlo así:
código java
Gato gato = nuevo Gato();;
gato.setXXX();;
daoimpl.addCat(gato);;
daoimpl.addMate(gato, compañero);;
Gato gato = nuevo Gato();; cat.setXXX();; daoimpl.addCat(gato);; daoimpl.addMate(gato, compañero);;
Primero persista cat y luego realice otras operaciones de persistencia en cat. Por lo tanto, los programadores de la capa empresarial deben saber en qué estado se encuentra el objeto cat, ya sea el primero o el tercero.
Si es el primer tipo, primero debe guardar y luego agregarMate; si es el tercer tipo, simplemente agregueMate directamente.
Pero lo más fatal es que si todo el software tiene muchas capas, el objeto gato que obtiene el programador de la capa empresarial puede ser el gato pasado desde la capa superior de la aplicación web, y él mismo no lo sabe.
Ya sea que cat sea VO, no haya persistido o haya persistido, entonces no tiene forma de escribir un programa en absoluto.
Por lo tanto, un DAOImpl de este tipo es obviamente problemático. Causará muchas trampas de programación para los programadores de la capa empresarial. Los programadores de la capa empresarial deben tener un conocimiento profundo de cada par de DAO que llaman.
Qué tipo de gestión de estado se lleva a cabo, es necesario tener un conocimiento profundo del estado exacto de su objeto PO en cualquier momento para garantizar la corrección de la programación. Obviamente esto es imposible, pero con.
saveOrUpdate, estos problemas se resuelven fácilmente.
Ahora necesitas modificar el método addMate:
código java
addMate public void (gato gato, compañero compañero);
Sesión sesión = ...;
Transacción tx = ...;
sesión.saveOrUpdate(gato);;
cat.addMate(compañero);;
tx.commit();;
sesión.cerrar();;
};
public void addMate(Cat cat, Mate mate); { Sesión de sesión = ...; Transacton tx = ...;
(gato);; gato.addMate(compañero);; tx.commit();; sesión.close();;
Como se indicó anteriormente, si el programador de la capa empresarial pasa un objeto PO que ha persistido, entonces Hibernate actualizará el objeto cat (suponiendo que el programador de la capa empresarial lo haya modificado fuera de la sesión).
atributo cat), si lo que se pasa es un objeto nuevo, guarde el objeto PO en la base de datos.
Por cierto: si Hibernate actualiza el objeto cat o guarda el objeto cat en este momento depende de la configuración de unsave-value.
De esta manera, los programadores en la capa empresarial ya no tienen que preocuparse por el estado de la PO. Para ellos, no importa si cat es un objeto nuevo, solo un VO, o si se consulta desde la base de datos.
Independientemente de los objetos PO, todos ellos se pueden agregar directamente a addMate:
código java
daoimple.addMate(gato, compañero);;
daoimple.addMate(gato, compañero);;
Esto es lo que hace saveOrUpdate.
Este artículo proviene del blog de CSDN. Indique la fuente al reimprimir: http://blog.csdn.net/zhrl0000/archive/2009/12/17/5027965.aspx.
-