Cómo dejar de hacer lo mismo

¿Le gusta repetir las operaciones de rutina de vez en cuando? Aqui estoy Pero cada vez en el cliente SQL cuando trabajaba con el repositorio de Rostelecom, tenía que registrar todas las uniones entre los identificadores de las tablas. ¡Y esto a pesar del hecho de que en el 90% de los casos, los campos y condiciones para unir tablas coincidieron de consulta en consulta! Parece que cualquier cliente SQL tiene funciones de autocompletar, pero no siempre funciona para almacenamientos: rara vez tienen una restricción única y una clave externa para mejorar el rendimiento, y sin esto, el programa no puede descubrir cómo se relacionan las entidades y qué puede hacer por usted para sugerir



Después de haber pasado por la negación, la ira, el regateo, la depresión y la aceptación, decidí: ¿por qué no intentar implementar el autocompletado con blackjack y como debería? Uso el cliente dbeaver escrito en java, tiene una versión de comunidad de código abierto. Un plan simple ha madurado:

1. Encuentra clases de autocompletar en código fuente
2. Reoriéntelos para que trabajen con metadatos externos y extraiga información sobre las uniones desde allí
3. ??????
4. BENEFICIO

Rápidamente descubrí el primer elemento: encontré una solicitud para ajustar el relleno automático en el rastreador de errores y encontré la clase SQLCompletionAnalyzer en el commit asociado. Miré el código, lo que necesito. Queda por reescribirlo para que todo funcione. Esperé una tarde libre y comencé a pensar en la implementación. Las reglas de vinculación de tablas (metadatos) decidieron liderar en json. No tenía experiencia práctica 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 json-simple de Google. Aquí comenzaron las sorpresas. Al final resultó que, dbeaver, como una aplicación tru, está escrito en la plataforma eclipse utilizando el marco OSGi. Para los desarrolladores experimentados, esto brinda la conveniencia de la administración de dependencias, pero para mí fue más como magia oscura, para lo cual claramente no estaba listo: como de costumbre, registro la importación de las clases que necesito de la biblioteca json-simple en el encabezado de la clase editada, lo especifico en pom. xml, después de lo cual el proyecto se niega categóricamente a ensamblarse correctamente y falla con errores.

Como resultado, logramos solucionar los errores de ensamblaje: registré la biblioteca no en pom.xml, sino en el manifiesto manifest.mf, según lo requerido por OSGI, mientras lo especificaba como paquete de importación. No es la solución más hermosa, pero funciona. Entonces apareció la siguiente sorpresa. Si está desarrollando una idea inteligente, no puede simplemente obtener y ejecutar la depuración de su proyecto basado en la plataforma eclipse: un desarrollador inexperto debería sufrir no menos que un analista sin completar automáticamente las solicitudes. Los propios desarrolladores de castores vinieron al rescate, indicando en la wiki todos los bailes con una pandereta que deben hacerse. Lo más molesto es que, incluso después de todas estas sentadillas, el proyecto no quería comenzar a depurar 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, logré sentir el inconveniente de usar json para mi tarea; después de todo, se suponía que los metadatos debían editarse manualmente, y para esto el formato xml es más adecuado. El segundo argumento a favor de xml fue la presencia en el JDK de todas las clases necesarias, lo que permitió dejar de pelear con una biblioteca externa. Con gran placer transfirí todos los metadatos de json a xml y procedí a editar la lógica de autocompletar.



Como resultado, hice cambios en las clases SQLUtils y SQLCompletionAnalyzer. La idea es esta: si el programa no pudo encontrar las oraciones de autocompletar adecuadas de acuerdo con la lógica básica, entonces verifica posibles uniones utilizando un archivo xml externo. El archivo en sí contiene pares de tablas que indican los campos por los cuales estas tablas deben vincularse. Las restricciones en las fechas de validez técnica de las entradas eff_dttm y exp_dttm y el indicador de eliminación lógica delete_ind se establecen de forma predeterminada.

Cuando se realizaron cambios en el código, surgió la pregunta: ¿quién completará el archivo de metadatos? Hay muchas entidades en el repositorio; no es rentable registrar todas las conexiones usted mismo. Al final, decidí colgar esta tarea en mis compañeros analistas. El archivo de metadatos se cargó en svn, desde donde se realizan los pagos en un directorio local con el programa. El principio es este: ¿ha aparecido una nueva entidad en el repositorio? Un analista hace posible las uniones al archivo, confirma los cambios, el resto realiza comprobaciones para sí mismo y disfruta trabajando autocompletar: comunidad, acumulación de conocimiento y todo eso. Realicé un taller para colegas sobre el uso del programa, escribí un artículo en confluencia: ahora la compañía tiene más de una herramienta conveniente.

Trabajar en esta función me permitió comprender que no hay que tener miedo de elegir proyectos de código abierto; por lo general, tienen una arquitectura clara e incluso el conocimiento básico del idioma será suficiente para los experimentos. Y con un cierto grado de perseverancia, incluso puede deshacerse de las operaciones rutinarias odiadas, ahorrándose tiempo para nuevos experimentos.