template - grails render view model

Beneficios de object.get() vs object.read() en Grails

Question

Estaba revisando algunos de los documentos de Grails y encontré this fragmento sobre el método read() en Grails. Si estoy entendiendo esto correctamente, puede extraer una versión de "solo lectura" de un objeto de la base de datos que solo se guardará en una llamada a save() explícita. Me parece entonces que debe usar una llamada de read() siempre que tenga un objeto que no espera que se modifique.

Pero, ¿por qué no usarías siempre una llamada de read() ? Como el objeto se cambiará por permisos de lectura / escritura si lo save() todos modos, ¿no sería más seguro leer el objeto en lugar de leerlo?

Answer 1

Probablemente estés en lo cierto, sería equivalente en la mayoría de los casos. Pero Hibernate no requiere que llame a save() ya que hace una comprobación sucia durante un color y dado que Grails usa un interceptor de "Abrir sesión en la vista", siempre habrá un color al final de cada solicitud. Esto sorprende a las personas que realizan cambios en una instancia recuperada por get() que solo deberían ser temporales mientras se procesa la vista, pero luego los cambios se mantienen de todos modos sin una llamada a save() . read() tendría más sentido en ese escenario.

Una optimización del rendimiento es utilizar http://grails.org/doc/latest/ref/Database%20Mapping/dynamicUpdate.html para insertar solo los campos modificados en la base de datos. El valor predeterminado es presionar todos los campos, cambien o no, ya que no es necesario generar un nuevo SQL para cada actualización. Si read() una instancia, Hibernate no conserva los datos originales, por lo que la actualización dinámica no sería posible, ya que no habría forma de saber qué campos están sucios.