¿Te gusta repetir operaciones rutinarias una y otra vez? A mí no. Pero cada vez que trabajaba con el almacén de Rostelecom en el cliente SQL, tenía que escribir todas las uniones entre las tablas manualmente. Y eso a pesar de que en el 90% de los casos, los campos y condiciones de unión de las tablas coincidían de consulta a consulta. Se podría pensar que cualquier cliente SQL tiene funciones de autocompletado, pero para los almacenes no siempre funciona: rara vez se establecen constraints únicos y claves foráneas para mejorar el rendimiento, y sin ello, el programa no puede saber cómo se relacionan las entidades entre sí y qué puede ofrecerte.
Después de pasar por la negación, la ira, la negociación, la depresión y acercándome a la aceptación, decidí: ¿por qué no intentar implementar el autocompletado por mi cuenta con blackjack y lo que haga falta? Uso el cliente dbeaver, escrito en Java, y tiene una versión comunitaria de código abierto. Se me ocurrió un plan sencillo:
- Encontrar en el código fuente las clases responsables del autocompletado
- Reorientarlas para trabajar con metadatos externos y obtener de ahí información sobre las uniones
- ??????
- PROFITS
Me familiaricé bastante rápido con el primer punto: encontré en el rastreador de errores una solicitud para corregir el autocompletado y en el commit relacionado Para trabajar con json decidí usar la biblioteca
json-simple de Google. Aquí comenzaron las sorpresas. Resulta que DBeaver, como aplicación legítima, está escrito en la plataforma Eclipse utilizando el marco OSGi. Para los desarrolladores experimentados, esta herramienta ofrece conveniencia en la gestión de dependencias, pero para mí se parecía más a magia oscura, para la cual claramente no estaba preparado: como de costumbre, escribo la importación de las clases que necesito de la biblioteca json-simple en la parte superior de la clase que estoy editando, la indico en pom.xml, después de lo cual el proyecto se niega categóricamente a compilarse normalmente y se cae con errores.
Corregir los errores de compilación resultó ser: la biblioteca no la escribí en pom.xml, sino en el manifiesto manifest.mf, como exige OSGI, especificándola como import-package. No es la solución más elegante, pero funciona. Aquí apareció la siguiente sorpresa. Si estás desarrollando en IntelliJ IDEA, no puedes simplemente ejecutar el depurador de tu proyecto, basado en la plataforma Eclipse: un desarrollador inexperto debe sufrir tanto como un analista sin autocompletado de consultas. Los propios desarrolladores de Beaver vinieron al rescate, indicando en la wiki todos los pasos necesarios. Lo más frustrante es que, incluso después de todos estos trámites, el proyecto no quería ejecutarse en modo depuración con la biblioteca JSON conectada a través de import-package (aunque aún se compilaba con éxito en el producto final).
Para entonces, ya había sentido la incomodidad de usar JSON para mi tarea; después de todo, se suponía que los metadatos debían editarse manualmente, y para eso el formato XML se adapta mejor. Un segundo argumento a favor de XML fue que en la JDK estaban todas las clases necesarias, lo que permitió dejar de luchar con una biblioteca externa. Con gran placer, trasladé todos los metadatos de JSON a XML y comencé a realizar ajustes en la lógica del autocompletado.
Ejemplo de metadatos
dim_account
dim_partner
dim_account
dim_branchComo resultado, yo en las clases SQLUtils y SQLCompletionAnalyzer. La idea es la siguiente: si el programa no pudo encontrar propuestas adecuadas de autocompletado según la lógica básica, verifica la existencia de posibles joins a través de un archivo XML externo. En el propio archivo se almacenan pares de tablas con la indicación de los campos por los cuales se deben vincular dichas tablas. Las restricciones sobre las fechas técnicas de acción de los registros eff_dttm y exp_dttm y la bandera de eliminación lógica deleted_ind se establecen por defecto.
Una vez realizadas las modificaciones en el código, surgió la pregunta: ¿quién se encargará de llenar el archivo de metadatos? Hay muchas entidades en el almacén, y se vuelve engorroso definir todas las relaciones uno mismo. Al final, decidí asignar esta tarea a mis colegas analistas. Subí el archivo de metadatos a svn, desde donde se hace el checkout en el directorio local con el programa. El principio es el siguiente: ¿ha aparecido una nueva entidad en el almacén? Un analista agrega los posibles joins al archivo, hace commit de los cambios, y los demás hacen checkout en sus propios sistemas y disfrutan de la autocompletación: comunidad, acumulación de conocimiento y todo eso. Organicé un taller para mis colegas sobre el uso del programa y escribí un artículo en Confluence; ahora en la empresa hay una herramienta más conveniente.
El trabajo en esta función me dio la comprensión de que no hay que temer hurgar en proyectos de código abierto; por lo general, tienen una arquitectura clara, y hasta unos conocimientos básicos del lenguaje son suficientes para experimentar. Y con una buena dosis de perseverancia, incluso se puede deshacerse de esas tediosas operaciones rutinarias, ahorrando tiempo para nuevos experimentos.
Fuente: habr.com
