Está en la página 1de 175

APLICACIONES CON BASES DE

DATOS ORIENTADAS A OBJETOS


EN DB4O
BASES DE DATOS
III
GRUPO I
¿Que significa db4o o db4objects?

Es la contracción de "database


for objects" que se traduce
como "base de datos para
objetos".
¿Cuales son las operaciones que puedo
realizar en db4o?
Básicas:
Set: graba objetos en la base
Get: recupera un objeto de la base a través
de un prototipo
Delete: elimina un objeto
Query: hace una consulta retornando una
colección de tipo ObjectSet
Commit y Rollback: confirma/anula una
transacción
Como Instalar el db4o en Java.-
La distribución db4o Java viene como un
archivo zip, db4o-8.0-java.zip. Al
descomprimir el archivo, se obtiene la siguiente
estructura de directorios:
Como Instalar el db4o en Java.-
Consideraciones con DB4o en Java.-
Para empezar, el com.db4o java paquetes y com.db4o.query
es todo lo que usted necesita preocuparse.

com.db4o

El paquete com.db4o Java contiene casi toda la funcionalidad


que normalmente se necesita cuando se utiliza db4o. Dos
objetos de la nota se com.db4o.Db4oEmbedded, y la interfaz
com.db4o.ObjectContainer.
Consideraciones con DB4o en Java.-
com.db4o.
ObjectContainer: Esta es la base de datos db4o.
Un ObjectContainer puede ser una base de datos en modo de usuario
único o una conexión de cliente a un servidor db4o.
Cada ObjectContainer posee una transacción. Todo el trabajo es
transaccional. Cuando se abre un ObjectContainer, usted está en una
transacción, cuando se cometen () o rollback (), la siguiente
transacción se inicia inmediatamente.
Cada ObjectContainer mantiene es propias referencias a los objetos
almacenados y crear instancias. De este modo, se logra la identidad de
objeto, y es capaz de lograr un alto nivel de rendimiento.
Consideraciones con DB4o en Java.-
ObjectContainers tienen la intención de
mantenerse abierto mientras se trabaja
en contra de ellos. Cuando se cierra una
ObjectContainer, todas las referencias a
los objetos de base de datos en la
memoria RAM se perderán.
Consideraciones con DB4o en Java.-
com.db4o.ext .-La interfaz de db4o se suministra en dos pasos
en dos paquetes de java, com.db4o y com.db4o.ext por las
siguientes razones:
- Es más fácil para empezar, porque los métodos son
importantes destacar.
- Será más fácil para los demás productos de copiar la interfaz
de db4o básicos.
- Es un ejemplo de cómo una versión ligera de db4o podía
mirar.
Consideraciones con DB4o en Java.-
Cada objeto com.db4o.ObjectContainer es
también un com.db4o.ext.ExtObjectContainer.
Se puede convertir en ExtObjectContainer o
puede usar el método para llegar a las funciones
avanzadas.
Consideraciones con DB4o en Java.-
com.db4o.config

El paquete com.db4o.config Java contiene los tipos y clases


necesarias para configurar db4o. Los objetos y las interfaces
dentro se discuten en la sección de configuración.
com.db4o.query
El paquete Java com.db4o.query contiene la clase predicado
para construir nativos consultas. El nativo de interfaz de
consulta es el principal db4o consultar interfaz y se prefiere en
la API de Soda consulta.
2. Primeros pasos para realizar
aplicaciones practicas con db4o.
Vamos a demostrar cómo almacenar, recuperar,
actualizar y eliminar los casos de una sola clase
que sólo contiene los miembros primitivos y
String.
En nuestro ejemplo será un Fórmula Uno (F1)
piloto cuyos atributos son su nombre y la F1
puntos que ya se ha ganado esta temporada.
2. Primeros pasos para realizar
aplicaciones practicas con db4o.
En primer lugar, crear una clase para mantener nuestros datos. Se parece a esto:
2.1. Apertura de la base de datos
Para acceder a un archivo de base de datos db4o
o crear una nueva, llamada
Db4oEmbedded.openFile () y proporcionar
Db4oEmbedded.newConfiguration () como una
plantilla de configuración y la ruta de acceso al
archivo de base de datos como el segundo
parámetro, para obtener una instancia
ObjectContainer. ObjectContainer representa "La
base de datos", y será su interfaz principal de
db4o.
2.1. Apertura de la base de datos
2.1. Apertura de la base de datos
DB4OFILENAME es sólo un valor de cadena que
representa el nombre del archivo. Si el archivo con este
nombre ya existe, se abrirá como base de datos db4o, de
lo contrario una base de datos db4o se creará una nueva.
 Para los siguientes ejemplos vamos a suponer que
nuestro entorno se encarga de abrir y cerrar la
ObjectContainer automáticamente, y almacena la
referencia en una variable llamada "db".
2.2. Almacenamiento de objetos.-
Para almacenar un objeto, simplemente llamamos sobre la base de datos, pasando por cualquier objeto como un parámetro.
2.2. Almacenamiento de objetos.-
Vamos a necesitar un segundo piloto, también.
2.3. Recuperación de objetos.-
db4o suministros varios sistemas de consulta
diferentes, consulta con el ejemplo (QBE), nativo
consultas (NQ) y el API de consulta SODA (SODA).
En este primer ejemplo vamos a introducir QBE.
Se crea un objeto prototípico de db4o para usar como
un ejemplo de lo que desea recuperar. db4o va a
recuperar todos los objetos del mismo tipo que
contienen la misma (no por defecto) los valores de
campo como el ejemplo. Los resultados se devuelven
como una instancia ObjectSet.
2.3. Recuperación de objetos.-
2.3. Recuperación de objetos.-
Para recuperar todos los pilotos de la base de datos, ofrecemos un 'vacío' prototipo:
2.3. Recuperación de objetos.-
Tenga en cuenta que se especifica 0 puntos, pero los resultados no
fueron limitados únicamente a los pilotos con 0 puntos, 0 es el valor
por defecto para los campos int.
db4o también proporciona un acceso directo para recuperar todas las
instancias de una clase:
2.3. Recuperación de objetos.-
Para JDK 5 también es un acceso directo genéricos, utilizando el método de consulta:

• Para consultar un piloto por su nombre:


2.3. Recuperación de objetos.-
Y a la pregunta de Pilotos con un número específico de puntos:
2.4. Actualización de los objetos.-
Actualización de los objetos es tan fácil como su almacenamiento. De hecho, se
utiliza el mismo número de stores (tienda) () para actualizar los objetos: sólo llame
store # () de nuevo después de modificar cualquier objeto.
2.4. Actualización de los objetos.-
Observe que la consulta para el primer
objeto. Este es un punto importante.
Cuando se llama a # guardar () para
modificar un objeto almacenado, si el
objeto no es "conocido" (habiendo sido
previamente almacenados o recuperados
durante el actual período de sesiones), db4o
insertará un nuevo objeto.
2.4. Actualización de los objetos.-
db4o hace esto porque no coinciden
automáticamente con los objetos a guardar, con los
objetos almacenados previamente. Se supone que va
a insertar un segundo objeto que pasa a tener los
valores de campo mismo.
Para asegurarse de que ha actualizado el piloto, por
favor, vuelva a cualquiera de los ejemplos de
recuperación de arriba y correr de nuevo.
2.5. Eliminación de objetos
Los objetos se eliminan de la base de datos usando el # método delete ().
2.5. Eliminación de objetos
Vamos a eliminar el otro, también.
2.5. Eliminación de objetos.-
Por favor, revise la supresión de los ejemplos
anteriores de recuperación.
Al igual que con la actualización de los objetos,
el objeto se va a eliminar tiene que ser
"conocido" a db4o. No es suficiente para
proporcionar un objeto prototipo con los valores
de campo mismo.
2.6. Conclusión
Tenemos almacenar, recuperar, actualizar y
eliminar objetos con unas pocas líneas de código.
 Ahora usted está probablemente interesado en
ver cómo la base de datos parece.
Vamos a echar un vistazo con la herramienta
gráfica de db4o - Administrador de objetos.
2.7. Codigo completo.-
2.7. Codigo completo.-
2.7. Codigo completo.-
2.7. Codigo completo.-
3. Administrador de objetos.-
Una vez que el gestor de objetos de la Empresa (OME) se instala se
puede ver en Eclipse, seleccione Ventana-> Abrir perspectiva->
Otros y elija "OMD". Por lo general, OME ventana debe ser similar
a esto:
3. Administrador de objetos.-
 En la perspectiva de la OME se puede ver:
- Menú de OME:
 Botones de OME barra de herramientas para acceder a la rápida funcionalidad de uso frecuente.
 Db4o Navegador: Ventana que muestra el contenido de la base de datos db4o abierta
 Propiedad Visor: Ventana que muestra las propiedades de la base de datos abierta o las propiedades de la clase base de datos seleccionada .
 Generar consulta: Ventanas que permitirán construir una consulta mediante arrastrar y soltar funcionalidad.
 Resultados de la Consulta: Ventana para ver los resultados de la ejecución de la consulta
3.1. Navegar por la base de datos.-
Vamos a crear una nueva base de datos y guardar algunos objetos en él ahora:
3.1. Navegar por la base de datos.-
Ahora podemos ver la base de datos resultante en el
Administrador de objetos. Por favor seleccione OME->
Conectar / Desconectar base de datos (o utilizar un botón
de acceso directo en el menú barra de herramientas) y
vaya a ome.db4o archivo en su carpeta de usuario.
(Normalmente es C: / Documents and Settings / [nombre
de usuario] en Windows XP/2000, C: / Users / [nombre de
usuario] en Windows Vista y / home / [nombreDeUsuario]
en sistemas * nix).
Una vez que haya conectado, aparecerá una pantalla similar
a esta:
3.1. Navegar por la base de datos.-
3.1. Navegar por la base de datos.-
La ventana de db4o navegador muestra que hay una clase en la base de
datos (piloto), que contiene dos campos: nombre y puntos. En el Visor de
la Propiedad se puede ver más información acerca de los campos de clase.
También puede cambiar "está indexado" campo y añadir el índice de la
base de datos pulsando el botón "Guardar índice" botón.
El panel del filtro en la parte superior de la vista permite una navegación
más fácil a través de la base de datos con una gran cantidad de diferentes
clases.
Usted puede utilizar búsquedas con caracteres comodín y se benefician de
la historia de la búsqueda para hacer la selección más rápida.
3.2. Consultas.-
Es fácil para recuperar todos los casos piloto de la base de datos:
simplemente haga clic derecho en la clase de piloto en db4o navegador y
seleccione "Ver todos los objetos". La lista de los objetos piloto se
muestra en la vista de resultados de consulta:
3.2. Consultas.-
Trate de cambiar los valores y el uso en el botón Guardar para
conservar los cambios en la base de datos. También puede utilizar el
botón Eliminar para eliminar objetos de la base de datos. Para los
objetos que contienen objetos de campo se le pide que utilice en
cascada en eliminar.
 Consultas más complejas se puede hacer usando Construir vista de
consulta:
3.2. Consultas.-
Arrastre "puntos" sobre el terreno de la vista db4oBrowser
en la vista en Generar consulta, establezca la condición
"mayor que", poner un valor "99" y ejecutar la consulta.
 Usted puede regresar a la ficha Consulta Piedra y modificar
la consulta más adelante otra vez. Por ejemplo: añadir "y"
creador, arrastre "nombre" de campo y establecer el valor a
"Michael Schumacher".
Vuelva a ejecutar la consulta.
Cuando la consulta se crea uno nuevo, la consulta anterior se
almacena y se puede seleccionar de la historia desplegable:
3.2. Consultas.-

Más consultas sofisticadas pueden construir uniendo


limitaciones agrupados utilizando "Agregar grupo". Cuando
haya terminado de trabajar con la base de datos de OME,
puede cerrar la conexión mediante el uso de OME->
Conectar / Desconectar comando de DB menú o utilizando el
botón equivalente de la barra de herramientas.
3.2. Consultas.-
Puede seguir utilizando OME al ir por el resto de este
tutorial. Si está utilizando la versión interactiva que se
encuentra la base de datos en el archivo formula1.db4o en su
carpeta de usuario. (Normalmente es C: / Documents and
Settings / [nombre de usuario] en Windows XP/2000, C: /
Users / [nombre de usuario] en Windows Vista y / home /
[nombreDeUsuario] en sistemas * nix).
Por favor, no olvide desconectar OME antes de ejecutar
cualquiera de los ejemplos del tutorial, ya que sólo una
conexión activa se permite que el archivo de base de datos.
4. Consultar.-
 Suministros db4o tres sistemas de consulta, consulta por (QBE) Consultas-
Ejemplo nativos (NQ), y la API de SODA. En el capítulo anterior, que se
presentó brevemente a consulta por ejemplo (QBE).
 Consulta-por-Ejemplo (QBE) es apropiada como una guía de inicio rápido
para los usuarios que todavía están aclimatando para almacenar y recuperar
los objetos con db4o.
 Nativo consultas (NQ) son la interfaz de db4o consulta principal, se
recomienda para uso general.
 SODA es el API subyacente interior. Se proporciona para compatibilidad
con versiones anteriores y puede ser útil para la generación dinámica de
consultas, donde NQ son demasiado inflexible de tipos.
4.1. Consulta por ejemplo (QBE)
Al utilizar consulta por ejemplo (QBE) le
proporcionará db4o con un objeto de la plantilla.
db4o devolverá todos los objetos que se ajustan a
todos los valores de campo no predeterminado.
Esto se hace a través de reflejar todos los campos
y la creación de una expresión de consulta en
todos los campos sin valor por defecto-se
combinan con expresiones AND.
4.1. Consulta por ejemplo (QBE)

Consultar este modo tiene algunas limitaciones evidentes:


• Db4o debe reflejar todos los miembros de su objeto de
ejemplo.
• No se puede realizar avanzadas expresiones de consulta.
(AND, OR y NOT, etc).
• No se puede restringir en valores como 0 (números
enteros), "" (cadenas vacías), o nulos (los tipos de
referencia), ya que se interpretaría como restricciones.
4.1. Consulta por ejemplo (QBE)
¡Tienes que ser capaz de crear objetos sin campos
inicializado. Esto significa que no puede inicializar
campos en los que se declaran. No se puede hacer
cumplir los contratos que los objetos de una clase sólo
se permiten en un estado inicializado bien definidos.
 Se necesita un constructor para crear objetos sin
campos inicializado.
Para evitar todas estas limitaciones, db4o proporciona
el nativo de consulta (NQ) del sistema.
4.2 Consultas Nativas.-
Consultas nativas son la interfaz de db4o consulta
principal y son el método recomendado para consultar
bases de datos desde la aplicación.
Debido a las consultas nativas sólo tiene que utilizar la
semántica de su lenguaje de programación, que son
perfectamente normalizado y una opción segura para el
futuro.
Consultas nativos están disponibles para todas las
plataformas soportadas por db4o.
4.2.2. Principio.-
Consultas Nativas proporcionan la capacidad de
ejecutar una o más líneas de código en todas las
instancias de una clase. expresiones indígenas
consulta debe devolver true para marcar casos
específicos como parte del conjunto de
resultados. db4o intentará optimizar las
expresiones de consulta indígena y ejecutarlos
contra índices y sin crear instancias de objetos
reales, siempre que sea posible.
4.2.3. Ejemplo Simple.-
Vamos a ver cómo un nativo de consulta simple se verá como en algunos de los
lenguajes de programación y dialectos que soporta db4o:
4.2.3. Ejemplo Simple.-
4.2.3. Ejemplo Simple.-
Consultas por convención. Una clase que amplía la clase com.db4o.Predicate se espera
que tenga un partido booleano # () con un parámetro para describir la extensión de
clases:
4.2.3. Ejemplo Simple.-
Cuando el uso de consultas nativas, no se olvide que los entornos
modernos de desarrollo integrado (IDE) puede hacer todos los
trabajos de mecanografía en torno a la expresión de consulta nativo
para usted, si utiliza plantillas y finalización automática.

Aquí es cómo configurar una plantilla de nativos de consultas con


Eclipse 3.1: En el menú, seleccione Ventana Preferencias + + Java +
+ Editor de plantillas + Nuevo
Como el tipo de nombre "nq". Asegúrese de que "java" es
seleccionado como el contexto de la derecha. Pegue el siguiente en el
campo del patrón:
4.2.3. Ejemplo Simple.-

Ahora usted puede crear una consulta de nativos con tres claves: n + q + Control + Espacio.
Características similares están disponibles en la mayoría de los IDEs modernos.
4.2.4. Ejemplo avanzada
Para consultas complejas, la sintaxis nativa es muy precisa y
rápida de escribir. Vamos a comparar a una consulta de
SODA que encuentra todos los pilotos con un nombre o una
puntuación dentro de un rango dado:
4.2.4. Ejemplo avanzada
Así es como la misma consulta se verá así con la sintaxis de consulta nativos,
totalmente abierto a la terminación automática, la refactorización y otras
funciones del IDE, totalmente verificados en tiempo de compilación:
4.2.5. Arbitraria de código.-
Básicamente eso es todo lo que hay que saber acerca de
las consultas nativas para poder utilizarlos de manera
eficiente. En principio se puede ejecutar código arbitrario
como consultas nativas, sólo tienes que tener mucho
cuidado con los efectos secundarios - especialmente
aquellos que puedan afectar a los objetos persistentes.

Vamos a ejecutar un ejemplo que implica un poco más


de la lengua funciones disponibles.
4.2.5. Arbitraria de código.-
4.2.6. Rendimiento de las consultas Nativas
Una desventaja de las consultas nativas tiene que señalar: Bajo
el capó db4o trata de analizar las consultas nativos para
convertirlos a SODA.
Esto no es posible para todas las consultas. Para algunas
consultas es muy difícil analizar el flowgraph. En este db4o
caso tendrá que crear instancias de algunos de los objetos
persistentes para ejecutar realmente el código de consulta de
origen.
db4o trataremos de analizar las partes de las expresiones de
consulta nativas para mantener instancias de objeto al mínimo.
4.2.6. Rendimiento de las consultas Nativas
El desarrollo del procesador de la optimización
de consultas nativo será un proceso continuo en
un diálogo cercano con la comunidad de db4o.
No dude en contribuir con sus resultados y sus
necesidades, proporcionando información a
nuestros foros db4o (Los foros son accesibles a
través de miembros db4o gratis).
4.2.7. Codigo Completo.-
4.2.7. Codigo Completo.-
4.2.7. Codigo Completo.-
4.3 Consultas de Soda API.-
La consulta SODA API de bajo nivel db4o de consulta de la
API, que permite acceder directamente a los nodos de los
grafos de la consulta.
Desde SODA utiliza cadenas para identificar los campos, no
es ni perfecta ni la seguridad de tipos comprobar en tiempo
de compilación y también es bastante detallado para escribir.
Para la mayoría de las aplicaciones nativas consultas será la
mejor interfaz de consulta.
Sin embargo no puede haber aplicaciones donde se requiere
la generación dinámica de las consultas, es por eso que
SODA se explica aquí.
4.3.1. Consultas sencillas.-
Vamos a ver cómo nuestras consultas QBE familiares se
expresan con soda. Un nuevo objeto de consulta se crea a través
de la consulta # () de la ObjectContainer y podemos agregar los
casos de restricción a la misma. Para encontrar todos los casos
piloto, se restringe la consulta con el objeto de la clase piloto.
4.3.1. Consultas sencillas.-
Básicamente, estamos cambiando nuestra "real" prototipo depara una
meta descripción de los objetos que nos gustaría cazar :un gráfico de
consulta formado por los nodos de consulta y limitaciones
Un nodo de consulta es un marcador de posición de un objeto de
candidatos, una restricción decide si se debe añadir o excluir a los
candidatos del resultado.
Nuestro primer sencillo gráfico se ve así.
4.3.1. Consultas sencillas.-
Sólo estamos pidiendo un objeto candidato (en este caso:
cualquier objeto en la base de datos) para ser de tipo piloto para
agregar nuestro resultado.
Para recuperar un piloto por su nombre, tenemos que restringir
aún más los pilotos candidatos al descender a su campo de
nombre y limita este con el candidato respectiva cadena.
4.3.1. Consultas sencillas.-
 Bueno, tal como lo hicimos en nuestra "real" prototipos, podemos unir las
restricciones a los miembros secundarios de nuestros candidatos.

• Así que un candidato tiene que ser de tipo piloto y tener un miembro llamado
'nombre' que es igual a la propuesta de cadena para ser aceptado por el resultado.
• Tenga en cuenta que la restricción de clase no es necesaria: Si lo dejamos fuera,
nos consulta para todos los objetos que contienen un miembro "nombre " con el
valor dado.
• En la mayoría de los casos esto no será el comportamiento deseado, sin
embargo.
• Encontrar un piloto por puntos exactos. Sólo hay que cruzar la primitivos de
Java / dividir objeto.
4.3.1. Consultas sencillas.-
4.3.2. Avanzada consultas
Ahora bien, hay ocasiones en las que no queremos para consultar
los valores de campo exacta, sino más bien por rangos de valores,
no los objetos que contiene dado valores de los miembros, etc Esta
funcionalidad es proporcionada por la API de restricción.
En primer lugar, vamos a negar una consulta para buscar todos los
pilotos que no son Michael Schumacher:
4.3.2. Avanzada consultas
Cuando hay negación, los operadores booleanos otro no puede
estar muy lejos.
4.3.2. Avanzada consultas
También puede limitar a una comparación con un valor dado
4.3.2. Avanzada consultas
La consulta API también permite consultar los valores por
defecto de campo
4.3.2. Avanzada consultas
También es posible tener clase db4o los resultados.
4.3.2. Avanzada consultas
Todas estas técnicas se pueden combinar de
forma arbitraria, por supuesto.
Por favor, pruébelo. Todavía puede darse el
caso de la izquierda donde las restricciones
predefinidas API de consulta puede no ser
suficiente - no te preocupes, siempre puedes
dejar que db4o ejecutar cualquier código
arbitrario que usted proporciona en una
evaluación.
4.3.2. Avanzada consultas
4.3.3. Conclusion.-
Cuál es el mejor para usar? Algunos consejos:
Consultas Nativas se dirigen a la interfaz principal de db4o, por lo
que debe ser preferido.
Con el estado actual del optimizador de consultas db4o puede
haber consultas que se ejecutarán más rápido en el estilo de
SODA, por lo que se puede utilizar para aplicaciones de
composición. SODA también puede ser más conveniente para
construir consultas dinámicas en tiempo de ejecución.
Consulta-por ejemplo-es bueno para un manejo sencillo de una
sola línea, pero limitado en funcionalidad. Si te gusta este
enfoque, el uso, siempre y cuando se adapte a las necesidades de
su aplicación.
4.3.4. Código Completo
4.3.4. Código Completo
4.3.4. Código Completo
4.3.4. Código Completo
4.3.4. Código Completo
5. Objetos estructurados.-
Es hora de ampliar nuestro dominio de negocio con otra clase y ver
cómo maneja db4o interrelaciones objeto. Vamos a dar a nuestros
pilotos un vehículo.
5.1. Almacenamiento de objetos
estructurados.-
Para almacenar un coche con su piloto, que acabamos de
llamar al # store () de nuestro objeto de nivel superior, el
coche. El piloto se almacenarán de forma implícita.
5.1. Almacenamiento de objetos
estructurados.-
Por supuesto, necesitamos una cierta competencia aquí. Esta
vez almacenar explícitamente el piloto antes de entrar en el
coche - esto no hace ninguna diferencia.
5.2. Recuperación de objetos
estructurados.-
5.2.1. QBE.- Para recuperar todos los coches,
simplemente proporcionar un 'blanco' prototipo.
Recuperación de Objetos
Estructurados
QBE.- Para recuperar todos los coches, que sólo
tiene que proporcionar un 'blanco' prototipo.
5.2. Recuperación de objetos
estructurados.-
También podemos consultar todos los pilotos, por supuesto.
5.2. Recuperación de objetos
estructurados.-
Ahora vamos a iniciar nuestro prototipo para especificar
todos los coches conducidos por Rubens Barrichello.
5.2.2. Nativo consultas.-
El uso de consultas nativas con las limitaciones de profundidad
objetos estructurados es sencillo, puede hacerlo al igual que lo
haría en otro código sin formato.
Vamos a limitar nuestra consulta sólo a los coches conducidos
por un piloto con un nombre específico:
5.2.3. SODA API de Consulta.-
Para utilizar SODA para consultar por un coche dado el
nombre de su piloto que tenemos que bajar dos niveles en
nuestra consulta.
5.2.3. SODA API de Consulta.-
También puede limitar el ámbito de piloto con un prototipo
para lograr el mismo resultado.
5.2.3. SODA API de Consulta.-
Hemos visto que descender a una consulta nos
proporciona otra consulta. Partiendo de una raíz de
consulta que puede descender en múltiples
direcciones. En la práctica esto es lo mismo que subir
de un niño a un padre y un descendiente a otro niño.
Podemos concluir que las consultas a su vez hace
referencia a uno-direccional en nuestros objetos en las
relaciones verdaderas. He aquí un ejemplo de que las
consultas para "un piloto que está siendo referenciado
por un coche, donde el modelo de coche es" Ferrari ":
5.2.3. SODA API de Consulta.-
5.3. Actualización de objetos
estructurados
Para actualizar los objetos estructurados en db4o,
nosotros lo llamamos simplemente # store () de nuevo.
5.3. Actualización de objetos
estructurados
Vamos a modificar el piloto, también.
5.3. Actualización de objetos
estructurados
Vamos a ver qué pasa si nos dividimos la tarea en dos
sesiones separadas db4o: En la primera, modificamos
nuestro piloto y actualizar su coche:
5.3. Actualización de objetos
estructurados
Y en el segundo, nos vuelva a comprobar nuestra
modificación:
5.3.1. Actualización de profundidad
Imagine un objeto complejo, con muchos miembros que tienen
muchos miembros de sí mismos. Al actualizar este objeto, db4o
tendría que actualizar todos sus hijos, nietos, etc.
 Esto supone una reducción del rendimiento graves y no será
necesario en la mayoría de los casos.
 La primera vez que hicimos la modificación, no db4o en realidad
tenía que recuperar el piloto modificado volvió el mismo que se
encontraba todavía en la memoria que hemos modificado, pero en
realidad nunca actualizó la base de datos.
Reiniciar la aplicación que muestran que el valor se mantuvo sin
cambios.
5.3.1. Actualización de profundidad
Para ser capaz de manejar este dilema lo más flexible
posible, db4o introduce el concepto de la profundidad de
actualización para el control de la profundidad del árbol
de un objeto miembro se atravesó en la actualización.
La profundidad de actualización por defecto para todos
los objetos es 1, lo que significa que sólo los miembros
primitivos y String se actualizará, pero los cambios en
los miembros del objeto no se refleja.
5.3.1. Actualización de profundidad
5.3.1. Actualización de profundidad
5.4. Eliminación de objetos
estructurados.-
Como ya hemos visto, hacemos un llamado # delete () en los
objetos para deshacerse de ellos.
5.4. Eliminación de objetos
estructurados.-
Bien, el coche se ha ido. ¿Qué pasa con los pilotos?
5.4.1. Borrado Recursivo.-
Usted ya puede sospechar que el problema del borrado
recursivo (y tal vez su solución, también) es muy similar a
nuestro problema de actualización de poco, y tienes razón.
Vamos a configurar db4o para eliminar piloto de un coche,
también, cuando el coche se elimina.
5.4.1. Borrado Recursivo.-
Una vez más: Tenga en cuenta que la configuración debe ser pasado a la llamada apertura ObjectContainer.
Recursiva eliminación revisited
Pero, un momento - ¿qué pasa si los hijos de un
objeto eliminado aún se hace referencia por otros
objetos?
Recursiva eliminación revisited
Recursiva eliminación revisited
Recursiva eliminación revisited
Houston, tenemos un problema - y no hay
solución simple a la mano. Actualmente
db4o no comprueba si los objetos a ser
eliminados se hace referencia en ningún otro
lugar, así que por favor tener mucho
cuidado al utilizar este característica.

Vamos a aclarar nuestra base de datos para


el siguiente capítulo.
Recursiva eliminación revisited
Conclusión.-
Esto en cuanto a las asociaciones de
objetos: Se puede conectar en un objeto
de la raíz y bajar por su gráfica referencia
a especificar consultas. Pero, ¿qué
valores múltiples objetos como matrices
y colecciones? Vamos a cubrir esto en
el próximo capítulo.
6. Colecciones y Arrays
Se moverá lentamente
hacia el procesamiento en
tiempo real los datos de
hoy con la instalación de
sensores para nuestro
coche y recogida de su
producción.
6. Colecciones y Arrays
6. Colecciones y Arrays
Un coche puede
producir la lectura
del sensor de
corriente cuando se
le solicite y
mantenga una lista
de lecturas recogidas
durante una carrera.

6. Colecciones y Arrays
6. Colecciones y Arrays
Nos limitan a los datos estáticos y no en el
momento y agregar flexibilidad durante el próximo
capítulos.
6,1. Almacenamiento
Este debe estar familiarizado por
ahora.
6,1. Almacenamiento
El segundo coche tendrá dos instantáneas de
inmediato en el inicio
6,2. Recuperar
6.2.1. QBE
En primer lugar vamos a verificar que en efecto han
tomado instantáneas.
6,2. Recuperar
Como un prototipo para una serie, le ofrecemos una gran
variedad del mismo tipo, que contiene sólo los valores que
esperar el resultado de contener.
6,2. Recuperar.-
Tenga en cuenta que la posición real de los elementos dados en la
matriz prototipo es irrelevante.
Para recuperar un coche por sus lecturas del sensor almacenados,
instalamos una historia que contiene los valores buscados.
6,2. Recuperar.-
También puede consultar las colecciones mismas, ya
que son objetos de primera clase.
6,2. Recuperar.-
Esto no funciona con matrices, sin embargo.
6.2.2. Consultas Nativas.-
Si queremos utilizar las consultas nativas para encontrar
SensorReadouts con los valores coincidentes, nos limitamos
a escribir esto como si queremos ver cada caso individual:
6.2.2. Consultas Nativas.-
Y así es como nos encontramos con coches que se
combina con los valores de lectura:
6.2.2. Consultas Nativas.-
6.2.3. consulta de API.-
La manipulación de matrices y colecciones es
análogo al del ejemplo anterior. En primer lugar, le
permite recuperar sólo la SensorReadouts con
valores específicos:
6.2.3. consulta de API.-
A continuación, vamos a llegar algunos coches que se
combina con los valores de Lectura:
6,3. Actualización y Eliminación.-
Este debe estar familiarizado, sólo tenemos que recordar que
debe tomar el cuidado de la profundidad de actualización.
6,3. Actualización y Eliminación.-
6,3. Actualización y Eliminación.-
No hay nada especial acerca de cómo eliminar las matrices y
colecciones, también. Eliminación de un objeto a partir de
una colección es una actualización, también, por supuesto.
6,3. Actualización y Eliminación.-
6,3. Actualización y Eliminación.-
Este ejemplo también muestra
que con db4o es muy fácil
acceder a los objetos internos
que nunca fueron
a ver. Por favor, tenga esto
siempre en mente y con
cuidado.)
Vamos a eliminar todos los
coches de la base de datos.
6,4. conclusión.-
Las colecciones son sólo objetos.
 Pero ¿por qué tenemos que
especificar el tipo ArrayList todo el
camino?.
¿Era necesario? ¿Cómo manejar la
herencia de db4o?.
7. herencia.-
Hasta ahora siempre hemos estado
trabajando con el concreto (es decir,
tipo más específico de un objeto. ¿Qué
pasa consubclases y las interfaces?.
Para explorar esto, vamos a diferenciar
los distintos tipos de sensores.
7. herencia.-
7. herencia.-
7. herencia.-
7. herencia.-
Nuestro mecanismo de auto instantánea se modificará en
consecuencia.
7. herencia.-
7,1. Almacenamiento
Nuestro código de instalación no ha cambiado en absoluto, tan sólo el funcionamiento interno de
una instantánea.
7,2. Recuperar.-
db4o nos dará todos los objetos del mismo tipo. Para
recoger todas las instancias de una clase dada, no importa
si son miembros de la subclase o instancias directas, que
acaba de proporcionar el correspondiente prototipo.
7,2. Recuperar.-
7,2. Recuperar.-
7,2. Recuperar.-
Esta es una situación
más que QBE podrían
no ser aplicables: ¿Qué
pasa si un tipo
determinado es una
interfaz o una clase
abstracta? Bueno, hay
un pequeño truco para
tener en cuenta: los
objetos de clase
reciben un tratamiento
especial con el
QBE.
7,2. Recuperar.-
Y, por supuesto, es nuestra API SODA:
7,2. Recuperar.-
7,3. Actualización y Eliminación.-
Es el mismo para todos los objetos, sin importar dónde
estén situados en el árbol de herencia. Al igual que se
recuperaron todos los objetos de la base de lo anterior,
podemos eliminar todos los objetos almacenados.
7,4. Conclusión.-
Ahora que hemos cubierto todas las
funciones básicas de OO y la forma en que
son manejados por db4o. Vamos a
completar la primera parte de nuestro
tutorial db4o en el próximo capítulo
observando gráficos de objetos, incluso
cuando la estructuras recursivas.
Gráficos Profundos.-
Ya hemos visto cómo db4o maneja asociaciones de
objetos, pero el ejemplo que sigue siendo bastante
plana y simple, en comparación con los modelos de
dominio del mundo real. En particular, no hemos visto
cómo se comporta db4o en la presencia de estructuras
recursivas.
Vamos a emular dicha estructura mediante la
sustitución de la lista de historia con una lista enlazada
implícitamente proporcionada por la clase
SensorReadout.
Gráficos Profundos.-
Modificar la clase de
SensorReadout
Gráficos Profundos.-
Gráficos Profundos.-
Los vehículos sólo mantiene una asociación con
una "cabeza" lectura del sensor ahora.
Gráficos Profundos.-
Gráficos Profundos.
8.1. Almacenamiento y Actualización
8.1. Almacenamiento y Actualización
Ahora nos gustaría construir una cadena de lectura del
sensor.
Ya sabemos acerca de la trampa de la profundidad de
actualización, por lo que configuramos el primero.
8.1. Almacenamiento y Actualización
8.2. Recuperando
Ahora que tenemos una
estructura lo suficientemente
profundo, vamos a recuperar de
la base de datos y lo atraviesan.
8.2. Recuperando
8.2. Recuperando
Todas estas lecturas pertenecen a una lista enlazada, por lo
que deben ser capaces de acceder a todos ellos con sólo
atravesar nuestra estructura de lista.
8.2. Recuperando
8.2.1. Profundidad de Activación
Esto es sólo la otra cara de la cuestión de fondo de actualización.
db4o no puede seguir cuando se está atravesando referencias de
los objetos recuperados de la base de datos. Por lo tanto, que
siempre hay que volver gráficos de objetos "completo" en la
recuperación - en el peor de los casos sería hervir a tirar todo el
contenido de la base de datos en la memoria para una sola
consulta.
Esto es absolutamente indeseable en la mayoría de las
situaciones, por lo que db4o provee un mecanismo para dar al
cliente grano fino control sobre la cantidad que quiere retirarse
de la base de datos cuando se pide un objeto.
8.2.1. Profundidad de Activación
Este mecanismo se denomina profundidad de activación
y funciona bastante similar a nuestra profundidad
actualización familiarizado.
La profundidad de la activación por defecto de cualquier
objeto es 5, por lo que nuestro ejemplo de arriba se
encuentra con valores nulos después de recorrer 5
referencias.
Podemos pedir dinámicamente objetos para activar sus
referencias a miembros.
Esto nos permite recuperar cada sola lectura del sensor
en la lista de la base de datos sólo cuando sea necesario.
8.2.1. Profundidad de Activación
8.2.1. Profundidad de Activación
8.2.1. Profundidad de Activación
Tenga en cuenta que las referencias 'corte' también
pueden influir en el comportamiento de los objetos: en
este caso, la longitud de la lista se calcula de forma
dinámica, y para ello limitada por la profundidad de la
activación.
En lugar de activar de forma dinámica elementos
subgrafo, puede configurar la profundidad de activación
estática, también.
Podemos decir a nuestros objetos de clase
SensorReadout a la activación en cascada de forma
automática, por ejemplo.
8.2.1. Profundidad de Activación
8.2.1. Profundidad de Activación
8.2.1. Profundidad de Activación
Hay que tener mucho cuidado, sin embargo.
Problemas de activación son difíciles. Db4o
ofrece una amplia gama de configuración de
cuenta para controlar la profundidad de
activación a un nivel de grano muy fino.
Encontrará los factores desencadenantes en
com.db4o.config.Configuration y las clases
ObjectClass y ObjectField asociados.
No te olvides de limpiar la base de datos.
8.2.1. Profundidad de Activación
8.3. conclusion
Ahora debemos tener las herramientas a su
disposición para trabajar con gráficos de objetos
arbitrariamente complejos. Pero hasta ahora sólo
han estado trabajando hacia adelante, con la
esperanza de que los cambios que aplicamos a
nuestro banco de datos preciosos son corregir.
¿Qué pasa si tenemos que volver a un estado
anterior, debido a algún fallo? En el siguiente
capítulo introducirá el concepto de transacción
db4o.

También podría gustarte