Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 12

Mesa Septiembre 2021

1. Definir persistencia por alcance. ¿Hay alguna condición que se debe dar para que
exista la persistencia por alcance?

RTA: Toda instancia a la cual se pueda llegar por una instancia persistente, es a su vez
persistente. Esto indica que para persistir objetos, basta con vincularlos con otro objeto
persistente.
Teoría 1 el profe dijo: Recuperar un objeto persistente, se vincula con algo nuevo y ese
nuevo se va a guardar automáticamente

En la clase de JPA dijo que las operaciones en cascada está relacionado a cómo quiero
manejar la persistencia por alcance. Generalmente se usa ALL.

CascadeType.ALL: se aplican todos los tipos de cascada.


CascadeType.PERSIST: las operaciones de guardado en la base de datos de las entidades
padre se propagarán a las entidades relacionadas.
CascadeType.REMOVE: las entidades relacionadas se eliminan de la base de datos cuando
la entidad propietaria se elimine.
CascadeType.DETACH: se separan del contexto de persistencia todas las entidades
relacionadas cuando ocurre una operación de separación manual.

2. ¿Existe el concepto de despersistencia por alcance? ¿Existe algo que lo "emule"?


El término lo inventó el profe…
Tiene que ver con la posibilidad de que cuando se rompen los vínculos de todos los objetos
hacia un objeto particular, ese objeto hasta incluso desaparezca de la bd, todo esto se
puede controlar con las características de cascada

3. ¿Qué atributo "fuerza" la desvinculación de objetos persistentes en una base de


datos?
RTA:Me parece que viene por el lado de las operaciones en cascada que están arriba

4. Utilizando persistencia por alcance ¿Cuál es el número mínimo de veces que se


debería llamar save()? ¿Por qué?
RTA: En un principio se puede argumentar que para mi sistema necesito solamente utilizar
un save(), es decir, ejemplo un banco… si me guardo un objeto banco solo debo vincular
todas mis clases a ese objeto y no necesitaría usar otro save.
Por otro lado, si yo uso una base de datos relacional podría ejecutar al iniciar la aplicación
un script donde realiza los inserts en la BD, de esta manera, solo necesito recuperar y
vincular los objetos. De esta forma, puedo tener un sistema sin save().

5. De todas las operaciones CRUD, ¿Cuál es la que se debería poner foco? ¿Por qué?
RTA: La operación que siempre necesito usar y debe estar optimizada es la recuperación
“R”. Porque para crear un objeto probablemente necesite recuperar otro para vincularlo,
para actualizar necesito recuperar la instancia y para eliminar necesito recuperar la
instancia y los colaboradores.

RTA(Palabras de Echu): Se se me ocurre que podría ser R, porque la información debería


estar disponible para leer siempre, y en el caso de que se quiera hacer una modificación a
lo sumo se verifica primero que siga existiendo o que no haya sido modificado por alguien
más, de ser así se actualiza la información vieja que se tiene y luego si se realiza la
operación

6. Explicar las estrategias de resolución de jerarquías. Explicar cuál sería las más
performante.

RTA:
[1] Si tuviera una clase vehículo, necesito identificar de alguna manera qué tipo de vehículo
es, si es camión, auto, etc. Quizás existan columnas que un camión no use porque son
propias de un camión.
Quiero buscar camiones, voy a tener que recorrer todos los autos.
7. ¿Se pueden aplicar dos estrategias de resolución de jerarquías a un mismo caso al
mismo tiempo? Explicar

RTA: Si. Un tipo de estrategia es posible que no me alcance para guardar la información y
cumplir con todas las user story que tengo.
Puedo haber elegido distintas estrategias.
Desventaja: guardo mucho pero hoy en día el almacenamiento no importa tanto.
Puedo tener triggers para insertar en varias tablas.

8. Explicar el patrón repositorio.


RTA: El patrón Repositorio nace de modelar la “R” del CRUD. El patrón consiste en crear
una clase que contenga todos los mecanismos de consultas y que funcione con un filtro.

El repositorio es una forma abstracta de acceder a un conjunto de objetos de la forma más


eficiente posible, voy a tener un repositorio por cada tipo de dato que quiero recuperar, se
usa para optimizar la recuperación.

Los repositorios son formas de recuperar objetos.

9. Explicar sobre Spring Data. ¿Por defecto, qué métodos ofrece?


RTA: Para usar spring debo declarar que es repositorio de mi clase y esto me permite
utilizar sus protocolos. find(), delete(), save(). Además, puedo re-definirla interfaz y crear los
protocolos que quiera.

Spring Data es uno de los frameworks que se encuentra dentro de la plataforma de Spring.
Su objetivo es simplificar al desarrollador la persistencia de datos contra distintos
repositorios de información .
Es uno de los módulos más grandes de Spring.
El principal objetivo de Spring Data es proveer una serie de herramientas que nos permiten
realizar integraciones sencillas con los diferentes entornos de información de datos que
tenemos.

Podemos extender de una clase de Spring Data, por ejemplo, para trabajar con repositorios

<Persona, Long>
Hace referencia a la clase Persona, y el segundo parámetro es el tipo de dato de la clave
primaria de la clase Persona
Spring Data construye consultas dinámicas, únicamente usando un nombramiento de los
métodos. Por ejemplo, si digo findByNombre(String nombre), el findeBy, es una instrucción
propia de spring data, y lo que sigue hace referencia a la propiedad por la cual voy a
construir la consulta dinámica, se buscan todas las personas que coincidan con el
parámetro nombre.

10. ¿Qué formas hay de declarar una query a la base utilizando Spring Data? Explicar
cada una de ellas.
RTA:
1. usar find() que vienen en la clase abstracta.
2. Los que yo defina como parte de la interfaz.
3. Configurando la consulta que se desea ejecutar Query(“”). Si cambio de base tengo que
cambiar acá.
4. Implementando de forma manual la consulta y haciendo que spring adopte nuestra
implementación.

11. Al cambiar el mecanismo de persistencia de un relacional a un no sql, ¿Qué capas


se deberían modificar? Explicar.
RTA: Cambia la capa de repositorio y la de modelo.
Lo que cambian o hay que implementar son los repositorios dependiendo de la tecnologías
utilizadas, esto es porque esta capa accede al tipo particular.
Podemos usar el por ejemplo, el @Query y dependiendo la tecnología va a cambiar la
consulta

Modelo, también cambia


La que tiene las entidades de mi dominio
Si usamos JPA tenemos que usar annotations para saber a qué tabla va y si es una entidad
que se guarda o no.
En mongo antes se usaba @Document y se especificaba el nombre de la colección, pero
ahora ya no se especifica nada.
Podemos evitar las annotation, usando un xml y ahí sí podría ser idéntico

Repositorio hay un poco de cambio y modelo suele haber cambio

Final Base de Datos 2


2° Llamado de Diciembre 2017
Aclaración: Las preguntas no son exactamente estas, es lo que recuerdo, de todos modos
las preguntas se repitieron todas en finales anteriores salvo la última que nunca había visto.

1. Diferencias entre Hibernate y JDO.


RTA:
- Hibernate analiza el código, mira los mapeos y genera las clases dinámicamente
mientras levanta el servidor. Proceso lento.
- JDO actua en compilación, más rápido. Toma un archivo con código JAVA, lo
aumenta con “enhancer” (agrega meta-data) generando un archivo aumentado con
código requerido para poder persistir las instancias.
Problemas: difícil de ver los errores y en distintos ambientes puede llegar a generar
distintos archivos aumentados.

2-. Para qué sirven los archivos .class aumentados (JDO). Describir el proceso de
aumento.
RTA:

El código Java se compila con javac y obtenemos el .class que es el bytecode de la clase
Java
Podemos tener metadata en un archivo separado .jdo o en forma de annotations
Aplicamos el enhancer, que se encarga de aumentar el código compilado con la metadata
que saca del archivo jdo o las annotations, y eso da como resultado una versión más
grande del código compilado. La ventaja de esto es que se hace en tiempo de compilación,
se analiza y ya se crean todas las clases que se necesitan, está todo compilado y armado
3. Defina Persistencia por alcance.
RTA: más arriba

4. Qué son los DTOs y para qué sirven.


RTA: Patrón DTO (Data transfer object)
Es un objeto cuya única funcionalidad es contener información respecto de otros
Es definido por el caso de uso
No tiene proxy, siempre se puede leer en cualquier capa, es un objeto común y corriente,
solo tiene get y set no tiene comportamiento
Snapshots de los objetos que están en la base

5.Que significa que la persistencia sea ortogonal.


RTA:

6. Características de OQL y diferencias con SQL. De un ejemplo que demuestra la


potencia de OQL.
RTA(según Echu): Con OQL podemos obtener todas las instancias de una clase, y a su vez
las sub instancias de esa clase si está conformada por otras clases.
Con SQL obtenemos tablas.
Un ejemplo sería si quisiera saber todas las tablas de una bd, tengo que consultar el
esquema y hacer un count, en cambio con OQL puedo hacer una consulta con FROM
Object y como todas las clases heredan de object vamos a tener todas las instancias
7. Principio de independencia de la Persistencia.
RTA:

8. Ejercicio XQUERY. Pone el archivo xml "informacion.xml" y con una consulta


xquery te pregunta qué es lo que retorna. (es el mismo ejercicio que está en los
finales anteriores)

9. Para qué sirve el patrón Proxy en la persistencia.


RTA(según Echu): Sirve para la performance. Se usa para no tener que traer a memoria
toda esa información en ese mismo momento, es lo que se conoce como lazy, lo trae bajo
demanda, se puede hacer si es una clase no final (una clase final no puede ser extendida)
Un proxy no trae la clase concreta hace un mockup de la misma
Un proxy no es de la clase que está “proxiando”, es otra clase que se parece mucho a la
que estás reemplazando, entiende exactamente lo mismo pero lo hace de otra manera

10. Cree un diagrama de objetos y ejemplifique consultas con JDOQL, tanto en su


forma como string como declarativa.

26/2/2021
1. Cual es el número de veces que se podría ejecutar la sentencia save en hibernate
para persistir un objeto.
RTA: Me bastaría con uno, para que todo mi modelo persista.
Patrón root object, se tiene que modelar el sistema como un objeto en sí mismo, si se
modela un banco debería aparecer la clase banco, con lo cual si hacemos un save de
Banco el resto se va a guardar en cascada

Si estamos usando una bd relacional puede pasar que podemos tener una app que no tiene
sentencia de guardado y aún así está guardando la información, porque podemos ejecutar
un script que lo primero que hace cuando estoy configurando el sistema la primera vez,
inserta en las tablas la información necesaria, por ejemplo, la que representa al banco,
entonces ya mi app sabe que el banco está creado con lo cual lo único que va a hacer es
recuperar y vincular los objetos y esos objetos se van a guardar automáticamente.

2. Definir persistencia por alcance. Hibernate la implementa por defecto o hay que
configurarla? ¿Cómo se llama el atributo xml que la configura?
RTA: Hibernate tiene persistencia por alcance pero no lo menciona abiertamente ¿por qué?
porque básicamente le conviene que escribamos .save .loquesea, porque esto complejiza
migrar de Hibernate a otra cosa.

3. Definir despersistencia por alcance. ¿Cómo se configura en xml? ¿Cómo se llama


el atributo?

4. Cuál crees que es la mejor estrategia para tratar las jerarquías en hibernate. (Libre
opinión, justificando la decisión). Se podría en hibernate plantear un esquema mixto?
¿Cómo funciona?

5. ¿Qué te parece mejor de hibernate, criteria, hql o sql?


RTA(según Echu): Todo termina siendo SQL y hasta acá llegué jaja
En HQL recibo instancias del objeto que consulté
Criteria, se hace una validación de la query antes de ejecutarse

HQL, lenguaje de consulta de hibernate, se monta y se traduce sobre SQL, siguen siendo
strings para java
Hibernate - Criteria Queries, se modela con objetos una consulta, se valida y se sabe de
antemano que va a funcionar, no falle porque por ejemplo que no exista la clase
Criteria se traduce a HQL y luego a SQL, es más lento

6. En mongo, si ejecutamos un update sobre una colección de documentos, ¿cómo


se actualizan estos? ¿Se actualizan todos? si falla alguno se cumple ACID?
RTA: Teoría 7 min 35 aprox. En Mongo puede pasar que algunos documentos se actualicen
y otros no, es decir no aplican todos los principios acid. Se pone en juego la disponibilidad.

RTA: En primer lugar al ejecutar un update sobre documentos, en caso de no existir algún
atributo, se creó y a los que existían les actualiza el valor.
En segundo lugar, en caso de producirse un fallo hay que revisar la ejecución ya que no se
cumple ACID. Si actualizo 5 registros y fallo, bueno, quedaron 5 actualizados y los otros no.
Cada ejecución devuelve un json con estadísticas.

También podría gustarte