¿Te gusta repetir las operaciones rutinarias una y otra vez? Entonces yo no. Pero cada vez que trabajaba en el cliente SQL con el almacenamiento de Rostelecom, tenía que registrar todas las uniones entre las tablas manualmente. ¡Y esto a pesar de que en el 90% de los casos los campos y condiciones para unir mesas coincidieron de una solicitud a otra! Parecería que cualquier cliente SQL tiene funciones de autocompletar, pero para el almacenamiento no siempre funciona: rara vez incluyen restricciones únicas y claves externas para mejorar el rendimiento, y sin esto el programa no sabrá cómo se relacionan las entidades entre sí. otros y lo que puede hacer por usted.
Después de pasar por la negación, la ira, la negociación, la depresión y la aceptación cercana, decidí: ¿por qué no intentar implementar el autocompletar con blackjack yo mismo y hacerlo de la manera correcta? Utilizo el cliente dbeaver, escrito en java, tiene una versión comunitaria de código abierto. Un plan simple ha madurado:
- Encuentre clases en el código fuente que sean responsables del autocompletado.
- Redirigirlos para que trabajen con metadatos externos y obtengan información sobre las uniones desde allí.
- ??????
- GANANCIAS
Descubrí el primer punto con bastante rapidez: encontré una solicitud en el rastreador de errores para ajustar el autocompletar y en el archivo relacionado descubrió la clase SQLCompletionAnalyzer. Miré el código y es lo que necesito. Sólo queda reescribirlo para que todo funcione. Esperé una tarde libre y comencé a pensar en la implementación. Decidí escribir reglas de enlace de tablas (metadatos) en json. No tenía experiencia práctica trabajando con este formato y la tarea actual fue vista como una oportunidad para corregir esta omisión.
Para trabajar con json decidí usar la biblioteca. de Google. Aquí comenzaron las sorpresas. Resultó que dbeaver, como aplicación real, se escribió en la plataforma Eclipse utilizando el marco OSGi. Para los desarrolladores experimentados, esto hace que sea conveniente administrar las dependencias, pero para mí fue más como magia oscura, para la cual claramente no estaba preparado: como de costumbre, importo las clases que necesito de la biblioteca json-simple en el encabezado de la clase editada, especifíquela en el pom.xml, después de lo cual el proyecto se niega categóricamente a ensamblarse normalmente y falla con errores.
Al final, logré corregir los errores de compilación: registré la biblioteca no en pom.xml, sino en el manifiesto manifest.mf, como lo requiere OSGI, mientras la especificaba como paquete de importación. No es la solución más bonita, pero funciona. Entonces apareció la siguiente sorpresa. Si está desarrollando en Intellij Idea, no puede simplemente comenzar a depurar su proyecto basándose en la plataforma eclipse: un desarrollador sin experiencia debería sufrir no menos que un analista sin completar la consulta. Los propios desarrolladores de castores acudieron al rescate, indicando en la wiki todos los bailes con pandereta que hay que realizar. Lo más molesto es que incluso después de todas estas sentadillas, el proyecto no quería iniciarse en depuración con la biblioteca json conectada a través del paquete de importación (a pesar de que todavía se ensambló con éxito en el producto terminado).
En ese momento, ya me había dado cuenta del inconveniente de usar json para mi tarea; después de todo, se suponía que los metadatos debían editarse manualmente y el formato xml es más adecuado para esto. El segundo argumento a favor de xml fue la presencia de todas las clases necesarias en el JDK, lo que permitió dejar de luchar con una biblioteca externa. Con gran placer, transfirí todos los metadatos de json a xml y comencé a editar la lógica de autocompletar.
Ejemplo de metadatos
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<tableRelations>
<tableRelation>
<leftTable>dim_account</leftTable>
<rightTable>dim_partner</rightTable>
<joinColumnPair leftColumn="partner_key" rightColumn="partner_key"/>
<joinColumnPair leftColumn="src_id" rightColumn="src_id"/>
</tableRelation>
<tableRelation>
<leftTable>dim_account</leftTable>
<rightTable>dim_branch</rightTable>
<joinColumnPair leftColumn="src_id" rightColumn="src_id"/>
<joinColumnPair leftColumn="branch_key" rightColumn="branch_key"/>
</tableRelation>
</tableRelations>Como resultado yo en las clases SQLUtils y SQLCompletionAnalyzer. La idea es la siguiente: si el programa no pudo encontrar sugerencias de autocompletar adecuadas usando la lógica básica, entonces verifica la presencia de posibles uniones usando un archivo xml externo. El archivo en sí almacena pares de tablas que indican los campos mediante los cuales estas tablas deben vincularse. De forma predeterminada, se establecen restricciones sobre las fechas de validez técnica de los registros eff_dttm y exp_dttm y el indicador de eliminación lógica eliminado_ind.
Cuando se realizaron cambios en el código, surgió la pregunta: ¿quién completará el archivo con metadatos? Hay muchas entidades en el repositorio, es costoso registrar todas las conexiones usted mismo. Como resultado, decidí asignar esta tarea a mis compañeros analistas. Publiqué el archivo de metadatos en svn, desde donde se realiza el pago al directorio local con el programa. El principio es el siguiente: ¿ha aparecido una nueva entidad en el repositorio? Un analista ingresa posibles uniones en el archivo, confirma los cambios, el resto verifica por sí mismo y disfruta del autocompletado funcional: comunidad, acumulación de conocimiento y todo eso. Realicé un taller sobre el uso del programa para colegas, escribí un artículo en Confluence: ahora la empresa tiene otra herramienta conveniente.
Trabajar en esta función me hizo comprender que no hay por qué tener miedo de jugar con proyectos de código abierto; por regla general, tienen una arquitectura clara e incluso un conocimiento básico del lenguaje será suficiente para experimentar. Y con cierta perseverancia, incluso podrá deshacerse de las odiadas operaciones rutinarias, ahorrándose tiempo para nuevos experimentos.
Fuente: habr.com