style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">

Derby JavaDB cuestiones

Hola JavaMéxico.

Hace poco estoy experimentando con Derby y me surguen algunas dudas.

Generalmente arranco la base de datos como un servicio tecleando en consola el comando: startNetworkServer y me pregunto ¿como podria configurar para que Derby esté escuchando peticiones en cualquier momento?
Al menos en postgresql el servicio inicia con el sistema y se mantiene pendiente por conexiones.

Además el otro detalle... si no inicio el servicio en el directorio donde anteriormente cree una base de datos no me conecta con ella.
En postgres que recuerde no importaba donde estuviera que el tenia la lista completa de todas las bases de datos creadas.
en Derby ¿como puedo cargar las bases de datos creadas así no estén todas en un mismo directorio ... o que no estén en el directorio donde me localizo cuando inicio el servicio?

Mi experiencia anterior en bases de datos es en postgres; Derby me parece algo extraño, como si fuera limitado ¿cual seria el motivo para las particularidades de derby? ¿es para fines diferentes a las demas bases de datos como postgres o que sucede?

Saludos.

Posdata: mis pruebas de esta base de datos son en linux.

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

Muy distinto

Comparar PostgreSQL con Derby es como comparar un Hummer con un Segway.

Derby es limitado, porque la idea es que puedas hacer una base de datos embebida, es decir que tu aplicación traiga su propia base de datos, de modo que el usuario no necesite instalar un servidor de base de datos aparte. Me parece que soporta conexiones por JDBC pero no está realmente diseñado para ser multiusuario.

Por ejemplo puedes correr tu aplicación y usar como DataSource una instancia de org.apache.derby.jdbc.EmbeddedConnectionPoolDataSource, con el nombre de la base de datos que quieres abrir. Para indicarle a Derby la ruta hacia dicha base de datos me parece que le podías pasar una propiedad de sistema. Hace unos años usé Derby para una pequeña aplicación que usaba su propia base de datos y me sirvió bastante bien, pero no encuentro el código (solamente encontré la referencia a esa clase).

Imagen de samz550a

gracias por la respuesta.

Hola.

He estado probando un poco esta base de datos para cosas superbasicas... inicialmente siguiendo un libro la utilicé como servicio... luego de perderme un buen rato con los jars, classpath pude ver un ejemplo con la base de datos embebida.
Por cierto, utilicé una propiedad del sistema para localizar la base de datos pero me dió impresión que eso no hace demasiado portable la aplicación... ... si coloco la base de datos en otro directorio diferente al que especifico en la propiedad del sistema habrá inconvenientes.......... creo que en postgres no era así, que postgres guardaba todas las bases de datos donde el sabia que estaban... creo. ¿habria alguna forma elegante de sobrellevar este inconveniente en Derby?

Comentas que la idea es que el usuario no necesite instalar un servidor de bases de datos aparte pero bueno, ...en el PC del usuario ¿habrá que instalarle Derby para que funcione la aplicación? quisiera creer que solo copiando la carpeta de los archivos generados por Derby para la Base de Datos fuera suficiente ¿estoy equivocado?

Y por cierto, agradezco una recomendación sobre lo que sigue:::::::::::
Cuando crean una aplicación de escritorio java y la instalan en el PC del usuario ¿donde guardan las librerias.jar utilizadas en el sistema de directorios o como le hacen? Por ahora lo que he intentado es O definir la variable CLASSPATH apuntando a un directorio O añadirlo a la carpeta jre/lib/ext en el JDK (ahora que lo veo el usuario no tendrá JDK sino solo la maquina virtual) ¿hay alguna otra forma de añadir las dependencias .jar de otra manera mas elegante?
........ de crear una pequeña aplicación con Derby y llevarsela al usuario tendré que añadir el .JAR necesario.

Ezamudio, seria genial contar con el código de la aplicación que mencionas, si en algun momento lo encuentras agradeceria su contenido. Lo de org.apache.derby.jdbc.EmbeddedConnectionPoolDataSource me recuerda el definir un bean DataSource en Spring... en tu caso ¿bajo que framework o de que forma lo utilizaste? Yo estoy utilizando un humilde Conection,y un humilde Statement para jugar con mi aplicación.

Imagen de ezamudio

Postgres

Nuevamente: PostgreSQL es un RDBMS completo multiusuario y se instala como un servicio aparte de las aplicaciones que lo van a usar, ni siquiera tiene que estar en el mismo equipo que la aplicación. Derby está hecho para bases de datos embebidas en la aplicación, guardando todo en filesystem, de modo que el usuario no necesite tener aparte un servidor de base de datos. Cómo logras esto en deployment? pues depende de cómo hagas deployment. Técnicamente lo único que necesita tu aplicación es tener disponibles las clases de Derby en el classpath (puedes meterlas en tu JAR de aplicación o agregarlas al classpath, no sé). Y sí, con que le pongas el directorio que trae todos los archivos de datos de Derby en su disco duro, y tu aplicación sepa dónde quedó dicho directorio, con eso es suficiente.

Me parece mala idea agregar los JARs al jre/lib/ext porque si el usuario decide actualizar su JDK o JRE y borrar el anterior, eliminará tus JARs. Los JARs deberían estar en el mismo directorio de la aplicación. Y para arrancarla puedes hacer un script (BAT en windows, o un sh en todo lo demás) que corra la app definiendo primero el classpath necesario.

Y sí, el datasource que trae Derby con pool de conexiones lo definí como un bean dentro de Spring.

Imagen de samz550a

Oye

Muchas gracias, me queda ahora todo mas claro :-D

Un gran saludo.

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">