¿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
Para trabajar con json decidí usar la biblioteca.
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
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