18/05/2009
02/06/2009
18/06/2009
El primer ORM Java se ha vuelto opensource. Se ha anunciado la versión 1.0 del proyecto Eclipse Persistence Services, también llamado EclipseLink. Este proyecto se volverá la implementación de referencia del estándar JPA 2.0, reemplazando a TopLink Essentials e inició cuando Oracle donó todo el código de TopLink para ello.
Como es de suponer, EclipseLink implementa JPA 1.0 (el soporte a la 2.0 será añadido más tarde), pero también soporta Service Data Objects 2.1 (SDO), MOXy (Binding a XML usando JAXB) y está listo para ser usado como un bundle de OSGi.
Al ser la implementación de referencia de JPA 2.0, EclipseLink se distribuirá junto con GHlassfish v3, los productos Oracle WebLogic e incluso con el SpringFramework.
Etiquetas: j2se, jpa, toplink, eclipselink
¡Hay que ver la cantidad de trabajo que está haciendo la gente para ahorrarse el trabajo de aprender SQL!
Ufff...como que si aprender SQL fuera "dificil" !! XD
Por favor anonimo, imagino que tu finalidad del comentario es solamente abrir una flame, pero si es ignorancia, deberias informarte mejor. Las ventajas son otras...Pero bue...Como ya he aprendido, no tiene sentido enseñar a alguien que no tiene intenciones de aprender.
En cuanto a la noticia, nunca tuve la oportunidad de utilizar TopLink pero ahora, esta noticia me entusiasmo a pegarle un vistazo.
Saludos.
#Anonimo
Definitivamente (como dijo jCalamaro) no tienes ni puñetera idea de que va esto verdad ???
#jCalamaro
Yo use SQL (PL/SQL) durante muchos años con bases de datos oracle(8i,9i, 10G y ahora 11G) y creo que si hay posibilidad de hacer ciertas sentencias SQL que llevan una complejidad un poquito mayor, que a alguien muy nuevo en el campo podria llegarle a costar un poco, así que decir que SQL es facil, pues creo que mejor decir que "no es muy dificil
En general, esta interesante la noticia, hay que ver como se va diversificando le mercado de productos open source, y como han ido estableciendo las pautas de como evoluciona la tecnologia.
Ahh pues bien por Toplink, yo lo he probado la version Essentials y va bastante bien, algo que me gusta es que no tiene otras dependencias salvo el JRE. Aunque la verdad utilizo Hibernate porque ya conozco su core mucho mas y hay veces que prefiero bajar una capa de JPA para llegar al persistence provider (Hibernate) y utilzar algunas funcionalidades que no tiene JPA todavia como un API de criteria.
No hay comparación aun con el mejor ORM de todos que se llamaba "KODO"!!! (hasta su version 3.4.1)(la version 4.1 no sirve)
Toplink es un muy buen ORM pero no es tan intuitivo como lo era KODO.
Por último Hibernate, este no es malo, funciona bien, pero he dedicado demasiadas horas a este ORM hasta darme cuenta que habia otros ORM que me permitian ser mas productivo.
jcalamaro, ya sé que sql es fácil.Por eso he dicho lo que he dicho.
Cambiando de tema, dime una sola ventaja de JPA sobre SQL (a pelo o con ibatis o similares)
#Anónimo.
En serio, no tienes ni la menor idea de lo que se trata el asunto, y con tu segundo comentario vaya que lo has demostrado.
Un ORM es un puente, hermano, entre dos mundos. SQL es excelente para el manejo de los datos en el modelo relacional, no hay quien le gane. Pero si quieres trabajar con objetos, sobretodo cuando has hecho tu conceptualización orientado a objetos de dominio, SQL necesita un apoyo. Un ORM sirve para conectar el mundo relacional y el orientado a objetos, cosa que SQL no hace por si solo.
Si tu quieres trabajar manipulando directamente las "tablas", no hay cosa mejor en Java que JDBC (ni siquiera necesitas iBatis, que es otra historia). Eso te lo va a decir todo el mundo. Si tu crees que es la mejor manera de hacer las cosas, pues es tu asunto.
Pero para todos aquellos que hemos disfrutado de la comodidad de un buen ORM (he usado TopLink e Hibernate, me quedo con Hibernate) para poder pensar en objetos y nada mas, esta noticia es muy interesante.
Pasaré a ver como van las cosas con ese proyecto de EclipseLink, aunque el nombrecito no me gustó nada.
JPA es diferente a SQL, tal vez podrias comparar JPQL o HQL con SQL porque los tres son lenguajes de consultas. JPA es un framework ORM estandar de Java, es mas puedes usar SQL desde JPA, pero es mas facil usar JPQL. La ventaja de JPQL y HQL es que son lenguajes de consultas orientado a objetos. Podrias usar navegacion como se utilizaras instancias de objectos por ejemplo.
Selecciona las personas que trabajen en alguna empresa de Colombia, ordenando las personas por la ciudades de colombia.
con JPQL harias
select per from Persona per where per.empresa.pais = "Colombia" order by per.empresa.ciudad;
En esa consulta Persona y Empresa son dos objetos diferentes (dos tablas), y obtienes la relacion persona-empresa solo navegando atravez del objeto persona. El ORM convierte esa consulta orientada a objetos a una consulta SQL nativa. Algo asi
select per from Personas per join to Empresa e where e.id = p.idEmpresa and
e.pais = "Colombia", orber by e.ciudad
Como puedes ver con JPQL te ahorras la preocupacion de tener en cuenta la relacion con la tabla empresa. Ahora bien alguien podria decir que es muy poca la diferencia, pero cuando hacer consultas mucho mas complejas si que complica todo. Ahh lo que recomiendan los fabricantes de ORM antes de usar algun Object Query Language es aprender SQL a pelo, porque obviamente sabras que esta pasando por debajo y podras analizar las consultas generadas. El otro punto fuerte es que la consulta JPQL te devolvera una coleccion de objetos Persona, mientras que la misma consulta SQL te devolveria un conjunto de datos sueltos (un ResultSet en el caso de JDBC)
Si quieres comparar JPA con algo deberia ser con JDBC u otros ORMS..
No soy el primer anónimo, pero creo que hay puntillo de validez detrás de lo que dice. Si lo quería decir es "usar un ORM no es excusa para no aprender SQL" creo que tiene toda la razón. Por muy super mega chachi guay que sea tu ORM, habrá momentos en que obtendrás ganancias muy, pero que muy importantes, en desarrollo, mantenimiento o en rendimiento usando SQL vs. usando el ORM. Y al revés, habrá veces que usando el ORM ahorres en desarrollo, mantenimiento o en rendmiento.
Si ponemos el punto del primer anónimo en el contexto habitual de un equipo de desarrollo, seguro que es fácil encontrar (vamos, no es que sea fácil, es que yo conozco casos) donde usar el ORM ha supuesto convertir en una cruz una parte del proyecto. Y todo porque, por simple ignorancia, no se usala otra posibilidad. Claro, para el que paga el desarrollo es más rentable invertir en capacitar al desarrollador en una sola cosa, y si el 80% del proyecto va de perlas con el ORM, pues para qué voy a pagar el tiempo de que esta persona aprenda SQL.
Luego están aquéllos desarrolladores que teniendo el tiempo y la oportunidad, no quieren salirse de lo que les "funciona" Esto ha sido así toda la vida, creedme, en su día había gente que intentaba construir una herramienta CASE ¡usando Clipper y dBASE! Pues eso, hay gente generando informes de 100 páginas usando el ORM y comiéndose una máquina entera para hacerlo.
El problema es que se considera la orientación a objetos como un fin es sí misma, no como un medio para desarrollar determinados (sólo determinados) sistemas. Yo he visto a equipos de trabajo utilizar JPA para sacar un simple listado (report), que se podría haber resuelto de forma mucho más eficiente con un select y un DTO (o, incluso, con un hashmap, pero esto no me atrevo a decirlo por si me apedrean los fanboys de los objetos).
Tercer anónimo en juego.
Indudablemente si nos planteamos las diferentes posibilidades a la hora de desarrollar una aplicación, está claro que deberíamos ajustar la solución a la dificultad de lo que se va a realizar. Esto desde el punto de vista de una aplicación independiente para un cliente que nunca más necesitaremos revisar ni mantener puede ser muy interesante. Pero por lo general en las empresas es muy común que los desarrollos software estén relacionados. Al estar relacionados más o menos, tarde o temprano a los desarrolladores les surge el deseo de intentar reutilizar al máximo los desarrollos. Es en ese momento en el que la orientación a objetos empieza a cobrar fuerza. Y cuando los típicos programas basados en partes sencillas desacopladas dejan de tener sentido. Es verdad que se podría montar una infraestructura propia basada en JDBC e intentar mantenerla, pero eso a la larga no es mas que algo problemático. Si bien es cierto que la eficiencia es mayor con JDBC las ventajas de usar JPA son muy grandes, por no hablar de que si vamos complicando más y mas nuestra arquitectura JDBC acabaríamos reintentando JTA a nuestra forma. Ya hay muchos IDEs que permiten automatizar muchos de los pasos de generación de clases y relaciones con la BD. Respecto a la eficiencia, bueno es cierto relativamente. Siempre existe la posibilidad de usar cache en muchos de los casos. Es cierto que no siempre, pero si en muchos casos. Además siempre se puede pisar cualquier solución. Y si no es suficiente JDBC, por que java y nuestra BD relacional no es lo suficientemente rápida. Y si tenemos que usar una base de datos tipo ADABAS y consultar a través de nuestro fantástico NATURAL?.
Personalmente pienso que el uso de JPA y en general de todas las tecnologías que nos lleven a la independencia de la BD son algo bueno para el software. Para mi manejar una base de datos relacional en cierta forma es un retraso comparable al uso de ensamblador hace algunos años. Esta claro que incluso hoy habrá muchos casos en los que sea necesario usar ensamblador o consultas directas a BD, pero pienso que cada vez sera menor el numero de casos. Todo esto es posible debido al ritmo de mejora del hardware. Dejando a parte las teorías fatalistas de las limitaciones previstas en el limite de frecuencia, dudo mucho que la potencia de los procesadores se quede parada dentro de unos años. De una forma u otra esto irá en aumento. No quiero tampoco iniciar una discusión al respecto. Debido a esta mejora a lo largo de los años programar en java cada vez ha cobrado más sentido(independientemente de las mejoras de rendimiento de la jdk a lo largo de los años). Ahora tenemos que plantearnos que JPA, EJB y otras tecnologías que no pretenden más que hacer próximo el mundo de los objetos que conocemos en UML a la programación son el camino a seguir. Esto tiene un precio que pagamos en el rendimiento y en dificultad a un nivel más bajo en la aplicación, pero la recompensa a nivel de reutilización, claridad en la estructura, extensibilidad de la aplicación o aplicaciones relacionadas, etc son enormes. El siguiente paso pienso que será un mayor uso de UML a través de los editores de los IDEs y de ahí a MDA al completo. Esto evidentemente es algo futuro, pero no tengo ninguna duda de ello. Con ese paso pagaremos aun más, pero obtendremos ventajas aun mayores además para entonces las máquinas serán aun mas potentes y no notaremos tanto ese precio.
Por todo esto pienso que discutir sobre la utilidad o no de JPA y de todas las tecnologías relacionadas es algo que no tiene ningún sentido. Es obvio que seguirá programándose que no haciendo análisis, diseño e implementación en estas tecnologías. Creo que los mayores detractores de la orientación a objetos son los que no comprenden el significado de lo que es, su esencia y lo que conlleva su uso. Lo pienso por que la gente que conozco que es detractora de estas tecnologías sabe poco de ellas, no las conoce y como tal las critica. Que conste que no defiendo usar la tecnología a toda costa. Entiendo que en ciertos casos muy concretos es útil usar el pasado, pero hoy por hoy tenemos que mirar al futuro en el desarrollo.
Respecto a la liberación de Top Link, me parece una gran noticia. He usado la versión Essential y me he encontrado con numerosas limitaciones por usar esta versión reducida. Hace tiempo vi una noticia sobre su futura liberación pero ya pensé que no iba a pasar.
PD. Nunca he usado KODO podríais señalar algunas ventajas en plan resumen? Tengo cierta curiosidad en el.
Para mi manejar una base de datos relacional en cierta forma es un retraso comparable al uso de ensamblador hace algunos años.
¡Qué razón tienes! Manejar una base de datos relacional es un gran retraso. Es preferible manejar una base de datos... OH WAIT!
Ahora en serio, exceptuando a las grandes corporaciones que usan mainframes de IBM, las corporaciones conservan sus datos en bases de datos relacionales (Oracle, etc.), así que no vas a tener más remedio que trabajar con bases de datos relacionales y SQL, lo quieras o no.
Y lo de comparar las bases de datos relacionales con el ensamblador... Bueno, mejor lo dejo ya, que, si no, me acusan de fomentar los flames. :-)
El tercero.
Claro que hoy por hoy tienes que usar base de datos relacionales. De la misma forma que el procesador que usas todos los días usa 1s y 0s, pero tu no tienes que introducírselos. A lo que yo voy no es a no usar bases de datos relacionales, sino a evitar usarlas directamente. Si ya existen formas para tratar con ellas desde más alto nivel sin tener que meterse en su complejidad, ¿para que vas a entrar en ellas para el desarrollo de aplicaciones?. Cosa aparte es que se necesite un administrador de base de datos, de la misma forma que necesitarás un administrador de sistemas o un soporte hardware.
Creo que el llegar a este punto de dejar un nivel por debajo a la base de datos depende lógicamente de la aplicación que se vaya a desarrollar. Puedo entender casos en los que no sea posible. También es probable que en ciertos puntos de la aplicación sea necesario un uso directo, pero por lo general creo que la tendencia será ir dejando a un lado el uso directo de la misma. De la misma forma que la máquina virtual puso una capa de abstracción entre un sistema operativo alojado en una máquina física concreta y tu programa.
La comparación ensamblador - bases de datos relacional era solo una comparación. Como cuando nos enseñan sumas y restas con cestas de frutas. No creo que nadie piense en ecuaciones diferenciales como un campo de cultivo subrealista.
No pretendía en ningún momento ser una flamereitor ni nada de eso, simplemente exponer mi punto de vista respecto a este tipo de tecnologías y a lo que a mi entender será el camino que se seguirá.
Obviamente depende de la situacion nunca debe generalizarse nada pero yo estoy enamorado de GORM
by Geek Programmer
Marioleon,
SQL no es PL/SQL.
Saludos,
Francesc Rosés
Para mi manejar una base de datos relacional en cierta forma es un retraso comparable al uso de ensamblador hace algunos años.
Pues ahi debo estar de acuerdo con anonimo y en desacuerdo con... anonimo, para algo sirven las "etiquetas" a que si? :P. La base de datos no es algo que genere tu programa para ejecutarse sobre el hardware ni es algo que se pueda "generar solo", esuna entidad independiente y que en muchos casos puede tener una vida bastante más larga que nuestro programa. Bien es cierto que hay programas donde la BDD es un mero almacen de datos "tonto" de lo que maneja el programa, pero son los menos y basarse en ellos para generalizar lleva a error.
Es un error muy común centrarnos unicamente en "el programa" y y olvidarnos que lo que normalmente tiene una vida más larga, son los datos. Un informático es algo más que un programador.
Tercero.
Cierto greeneyed que los datos tienen su importancia. Hay gente que desarrolla aplicaciones en torno a los datos, otros al rededor del proceso. Yo personalmente pienso que a modo genérico, ambas cosas son importantes. Pero si hablamos de usar la base de datos desde JPA y optimizas la base de datos a través de un administrador, la base de datos en si misma deja de tener ese protagonismo constante. Es como si para cada proyecto nos molestasemos en optimizar el sistema de ficheros de forma perfecta para nuestro caso concreto. Los datos en un modelo de aplicación basado en JPA o similar siguen estando ahí en la base de datos. Y por debajo de eso, las tablas estan almacenadas en un sistema de ficheros ( sea ZFS, EXT3 o lo que sea) montado por un sistema operativo. Pero no hablamos del sistema de ficheros para cada paso que damos en la aplicación. El que usemos JPA no implica que cuando hagas una transacción desde tu modelo de negocio no se inserten datos a tu base de datos. La unica implicacion es que tu no has creado esas consultas en tus clases de modelo. Ni has tenido que gestionar las transacciones ni muchas otras cosas que en si JPA ya resuelve. Podríais decirme que muchas aplicaciones no necesitan esto. Probablemente tambien se dijo lo mismo de java hace muchos años: para que quiero una máquina virtual si siempre voy a programar en C bajo esta maquina X86.. yo no necesito que sea multiplataforma...
La dificultad que tenemos al usar un mundo de bases de datos relacionales que no se corresponden con el mundo de objetos que solemos usar y la cantidad de problemas que causa el mal uso de una tecnología que reinventamos con cada programa que hacemos en JDBC, con los riesgos de leaks de memoria o de conexiones, statements o resultsets mal cerrados, creo que justifican en gran medida el uso de JPA que resuelve muchos de estos problemas. Es cierto que hoy por hoy si el rendimiento es un necesario en la aplicación o si esta en si misma es muy sencilla y no pretende ser aumentada, no tiene sentido usar JPA cuando con un acceso más directo se acaba antes. Pero para desarrollar aplicaciones medianas o grandes con relaciones con más aplicaciones complejas, y esto no creo que sea algo muy raro, tiene mucho sentido el usar JPA.
Ciertamente la base de datos no es algo independiente, como tampoco lo es el sistema operativo. Y es cierto que en ocasiones tenemos que comunicarnos con el directamente, a pesar de estar tras una máquina virtual. Como también es cierto que aunque usemos JPA, habrá veces que tengas que comunicarte con la base de datos. Pero creo que es algo que cada vez se hará menos.
Claro que un informatico es algo mas que un programador, pero también es mucho mas que un administrador de oracle. Conozco también a mucha gente que centra su aplicación entorno a la base de datos, especialmente la gente que usa oracle.
En el ciclo de vida de una aplicación, si tienes suerte, puedes hacer análisis, diseño, implementacián y pruebas en varias iteraciones y en esas fases apareceran nuestros fabulosos diagramas de clases, de estados, etc. Ese UML que usado con MDA debería ser nuestro objetivo algún día, esta centrado en el diseño a través de modelos. Luego al final en el paso a diseño e implementación pasamos a transformarlo a la plataforma real. Si es oracle, pues fantástico, pero quizás algún día quieras portarlo a otra base de datos. Usando JPA y frameworks cada vez de más alto nivel, estos cambios acabarán siendo comparables a cambiar de sistema en java. Lógicamente tiene su trabajo pero es menor que portar un programa en c++.
Evidentemente en la vida real MDA no está con nosotros aún(al menos en la mayoría de casos), pero si es cierto que podemos hacer una aproximación en la medida que nos dejen los tiempos y los recursos con que contemos. Pienso que una aplicación tiene que girar en torno a modelos más que a modelos en una base de datos relacional. Que acabemos en ella es cosa muy distinta. Creo que el uso de JPA es un paso más que nos acerca al desarrollo de aplicaciónes en esta dirección. Supongo que con las siguientes especificaciones de EJB y JPA esto cada vez sera más una realidad.
La base de datos [...] esuna entidad independiente y que en muchos casos puede tener una vida bastante más larga que nuestro programa.
¡Por fin alguien entiende que la base de datos es LO IMPORTANTE!
La mayoría de las empresas mantiene la misma base de datos durante años, o incluso decenios (como mucho, se actualiza de versión). En cambio, los programas en perl o en php o en java o en [pomga aquí su lenguaje favorito] son efímeros. Entonces, ¿por qué hay que ocultar la base de datos con capas, y más capas?. Yo, francamente, prefiero trabajar directamente con SQL sobre JDBC, nada de JPA. Y, si mi empresa tuviese un mainframe de IBM, utilizaría la tecnología de consultas que éste tuviese (no la conozco) y no la ocultaría con capas y capas y capas...@"Tercero", supongo que lo habras puesto para identificarte: Yo no digo que no se pueda o deba usar JPA en muchos casos, pero de ahi a considerar que las BDD relacionales son como un sistema de ficheros... hay un trecho muy muy largo.
Quizá llegue un día en eso sea así, pero mientras tanto aun quedan bastantes años de prestarles la atencion debida a las BDD.
Y tampoco estoy de acuerdo en esa visión que impera ahora de que lo de las bdds relacionales es una "molestia" para hacer lo que toca, que es hacer el programa y "algo" ya se encargará de almacenar los datos. Las BDD son relacionales por que a día de hoy son la forma eficiente de hacerlo en muchos casos, y pretender que es una molestia es lo mismo que ocurre con las conexiones remotas y las redes. Uno puede intentar engañarse y poner unas capas por encima para hacer ver que no estan ahí, pero aunque se usen las capas, hay que saber que estan ahi, y como funcionan por que la técnica no ha avanzado lo suficiente para que la abstracción sea realmente total y eficiente. Simplemente no estamos a esa altura.
De la misma forma que estan las famosas "Falacias de la computación distribuida", tendrían que hacer las de el uso de BDD.
http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing
El día, cuando llegue, que podamos tratar las BDDs igual que ficheros seré el primero en no molestarme en aprender como funcionan por debajo, de firma forma que no me estudio como funcionan internamente y le dejo eso a los DBAs, pero hasta entonces, aun cuando uso JPA se perfectamente lo que esta haciendo por debajo y por que uso eso y no hago JDBC a pelo.
Tercero.
De acuerdo con todo lo que hablas greeneyed. Lo que has dicho no se opone a mi visión. Conocer la base de datos es algo fundamental. Igual que conocer como funciona un ordenador de principio a fin y como se ejecuta un programa desde su parte mas básica a la mas compleja. No en una profundidad exhaustiva pero si a un nivel de conocimiento aceptable. Logicamente según la parte en que nos centremos. Conocer el funcionamiento a nivel de transistores de un procesador es importante, pero prefiero saber el funcionamiento de una base de datos relacional. A nivel academico estoy totalmente de acuerdo con un enfoque de conocimiento general con alguna especialización. Por eso es super importante saber que hay debajo. Yo personalmente uso MySql5, bajo Solaris 10 y GlassFish 2 brevemente desplegados en una máquina basada en UltrsSparc T2 y he dedicado muchísimo tiempo a labores de configuración y tuneo de cada parte y lo que me queda. De hecho hay relaciones entre estos elementos que solo el desarrolldador de la aplicación puede llegar a conconer y que se le escapan a un administrador de Solaris o uno de MySql. Todo eso es fantástico, pero es algo que espero el tiempo vaya dejando atrás. Cuando me refería al ensamblador era por que hace 10 años por ejemplo hice un programa en Pascal que necesitaba más velocidad y no tuve más remedio que usar ensamblador. Algo tedioso, pero que por otro lado me gustaba y gusta. Eso hoy por hoy es raro encontrarlo en una apliación. Me gustaría saber si los juegos actuales hacen un uso intensivo de ensamblador o les basta con openGL y directX. No lo tengo claro.
El tema de las capas y capas no es algo malo en absoluto. No hay ningún problema en usarlas siempre que sepas que es lo que vas a perder y que vas a ganar. Con el tiempo las ventajas serán cada vez mayores y probablemente nuestro conocimiento de las partes de debajo serán menores. Dudo que haya aquí mucha gente que conozca a un nivel profundo el funcionamiento de la jvm respecto a un sistema operativo en una determinada arquitectura, más que nada por que somos personas no ordenadores y no tenemos tanto tiempo en el dia para saber tantas cosas. Por ello creo que en un futuro el funcionamiento interno de las bases de datos relacionales, si no cambian a una version mejorada de las bd orientadas a objetos quien sabe, serás algo en lo que tendremos que dedicar menos tiempo o nada.
Como nota a parte respecto al desarrollo a través de modelos, fijaos como en el roadmap del plug in de netbeans 6.1 está prevista la generación de codigo de UML a EJB entre otros. Esto nos permitirá en unos pocos años hacer ciclos de ingeniería directa e inversa según nuestras necesidades. Creo que JPA es una pieza de un futuro muy emocionante en el desarrollo software, aunque para poder disfrutarlo necesitemos tener un xeon de 80 cores de esos. Pero todo eso llegará. Y después... bueno aquí es donde podríamos iniciar una conversación sobre estos apasionantes temas de despertar la materia y como nos quedaremos sin trabajo en 2020.
Totalmente de acuerdo pues :). El unico problema es la gente que salta directamente a JPA sin saber lo que hay debajo, ya que como todavia no estamos en el punto en el que se pueda ignorar, luego vienen los problemas.
Respecto a lo de los temas de quedarnos sin trabajo... uff, lo han dicho tantas veces y de formas tan distintas que ya no presto mucha atención. Antes de automatizar la tarea de crear software, tendríamos que tener claro como hacerlo y saber especificarlo sin ambiguedades... y para eso, al menos en el tema de web, nos queda muuuuucho camino.
¡Qué bien! ¡Otra implementación más de JPA, con sus decenas de bugs! Da igual que tenga bugs. Lo importante es que sea lo más de lo más.
Otra implementación más de JPA
Tu si que te enteras bien. Le han cambiado el nombre y le han añadido cosas pero ya estaba, y de hecho era/es la implementación de referencia.
Greeneyed, aunque eclipselink ya existiese, no deja de ser una de las muchas implementaciones de JPA. Y digo "muchas" porque con que hubiese una, sería suficiente.
jajaja, conformismo estilo .NET en el aire, si necesitas pan, comes pan, el mismo pan de siempre. En Java si necesitas pan puedes escoger el mas sabroso para ti, pan con bocadillo? pan de ajo? pan de mantequilla? xD mmm ya me dio hambre.
Tener de donde escoger siempre me ha parecido muy muy bueno, hay ciertos incomvenientes aveces y es que hay "muchas" implementaciones de lo "mismo" y tocaria probar varias para saber cual elegir, pero yo eso no lo veo tan mal. Que pasa cuando tienes una sola opcion en el camino?? Pues entonces solo te toca esa y punto. Y si esa opcion tiene "decenas de bugs" y te das cuenta de que en realidad no te sirve?? Pues te toca apretar el trasero y rogar que tus clientes no se den cuenta de los fallos o en el mejor de los casos "hacer" algo propio sin las decenas de bugs menos decenas de funcionalidades mas docenas de nuevos bugs... :D
BBDDR -> Donde esta la capacidad de evolución (más alla'de vistas ...)? cambios de esquemas, migraciones, compactaciones, OLTP, Datawarehouse, BI, históricos, calidad de los datos ...: Cuando los sistemas de bbdd sean capaces de tener en una única instalación toda la flexiblidad que le pedimos al código que las usa me parecerán gran cosa ... Gracias a la falta de flexibilidad de las bbdd y su falta de funcionalidad come mucha gente ... Pero los datos son muy "importantes" (aunque sean contradictorios y no hayan pasado controles de calidad) y el código es efímero, temporal e invisible ...
El rollo antropológico de los datos frente a los procesos les permite a muchos aprovecharse ... Alguien que fuera un experto en BBDD hace 10 años (y se hubiera pasado esos 10 años congelado) seguiría siéndolo ahora. Alguien que fuera un buen desarrollador según los estándares y las herramientas de entonces tras su descongelación engrosaría las listas del paro ...
Las BBDD relacionales son una tecnología madura, un mal necesario en algunos casos ... Es como una casa vieja sin luz ni ventanas al exterior a la que todos los años redecoramos con muebles de Ikea ... Nadie (al menos yo) está "casado" con la OO per-se sino con muchas de las características y ventajas que proporciona, si viene algo mejor (más flexible sin perder control, mas eficiente sin perder comprensibilidad ...) lo aprenderé y lo usaré (lo mismo que uso scripts, partes declarativas, partes funcionales, configuración, transformo código poco flexible en procesos configurables mediante datos ...).
Tengo mucho respeto por los campos "maduros", pero que no me cuenten milongas de que es la solución perfecta y de que nunca más van a evolucionar.Por ejemplo: SQL -> Tutorial D (Uno de cuyos autores, por ejemplo, es Date, no precisamente un ganapán en BBDD ...). Otro asunto es que lleva más de 20 años hacer que nuevas tecnologías pasen de la investigación al uso común en las empresas (y si ya hay usa solución que más o menos funciona pues cuesta aun más) ...
Greeneyed, aunque eclipselink ya existiese, no deja de ser una de las muchas implementaciones de JPA. Y digo "muchas" porque con que hubiese una, sería suficiente.
Pues sigo pensando que no lo entiendes. JPA es una especificación, precisamente por eso y gracias a eso hay multiples implementaciones. Si no hubiera mas que una ¿De que nos serviria que fuera una especificación? De nada. Lo que dices no tiene ningun sentido.
Tengo mucho respeto por los campos "maduros", pero que no me cuenten milongas de que es la solución perfecta y de que nunca más van a evolucionar.
Nadie dice que sean la solucion perfecta ni que vayan a evolucionar, pero de momento la historia dice que evoluciona mucho mas rapido y el codigo, asi que las probabilidades de que cambie este antes que las BDD son mayores. Y aunque estuvieran en ficheros. Lo unico que decimos es que tambien hay que prestar atencion a los datos, que no se guardan solos. ojalá.
Otro asunto es que lleva más de 20 años hacer que nuevas tecnologías pasen de la investigación al uso común en las empresas
Vaya, habra que contarselo a todas esas empresas que llevan un ratillo usando Java cuando Java no llega apenas a 13-14 años... ¡¡¡Nos hemos adelantado la tira de años!!!:)
Escribe tu comentario