iidec / Integra.Space.Language-upstream

Lenguaje de consulta que permite el acceso a datos en tiempo real
0 stars 0 forks source link

Eliminar NodeText de PlanNode #58

Open OscarCanek opened 7 years ago

OscarCanek commented 7 years ago

Actualmente se genera el texto de un nodo para almacenar la instrucción que se parsea con el objetivo de almacenarla en la base de datos para usarla a futuro.

Consideraciones Para generar la cadena de texto de la instrucción que se esta parseando se hace un recorrido por todos los nodos hijos hasta llegar a las hojas. Esto conlleva a que entre mas hijos tenga el nodo de donde se esta generando la cadena de texto, mas carga se genera en el sistema, sumado a que se llama en mas de un nodo.

Actualmente la cadena se genera únicamente con el objetivo de almacenarla en la base de datos.

Propuesta Debido a las consideraciones planteadas se propone el cambio de eliminar la generación de la cadena durante la compilación y este proceso sea sustituido por uno en donde se genere la cadena del comando a partir de la información almacenada en la base de datos.

Esto también beneficiaría al momento de cambiar de versiones debido a que no habrían versiones viejas de comandos en la base de datos y todos los problemas que esto conllevaría a la hora de re-ejecutarlos entre versiones de motores (el generador generaría scripts para una versión seleccionada).

marianogenovese commented 7 years ago

Cual seria el algoritmo de reversa para obtener el código?

OscarCanek commented 7 years ago

Hay que definirlo aun pero en general cada comando tendría su propio algoritmo, donde habría una relación entre (Objeto del sistema) <-> (Comando). En la base de datos esta toda la info del objeto del sistema.

marianogenovese commented 7 years ago

Habria que definir el nivel de eso, por ejemplo guardarías el operador de comparación entre dos campos en un where? o guardarías el orden de evaluación en un where si hay parentesis por ejemplo? otra alternativa para iniciar es guardar el texto que representa el comando no por nodo sino en el root como un todo. Sql lo guarda como un todo o como el usuario lo creo mira syscomments no aplica para las tablas solo para algunos objetos.

OscarCanek commented 7 years ago

Si, tiene razón ahi ya se complica la cosa, lo había visto desde el punto de vista de los DDL sin consultas. ¿Que sería lo correcto: guardar el batch ejecutado o comando por comando?

marianogenovese commented 7 years ago

Lo correcto es guardar comando por objeto que represente, un stream persistente tendria un registro con el id del objeto y el texto que representa. No todos los comandos van a estar guardados.

OscarCanek commented 7 years ago

Actualmente la consulta de un stream persistente es una cadena de texto separada, esa si es posible almacenarla en la base de datos tal cual la escribió el usuario, puede ser almacenado por versión y por corrección. Básicamente sería la única cadena que se almacenaría y por lo demás (pregunto) ¿Podría ser como SQL Server que genera el sql a partir de un objeto almacenado en la base de datos ya sea "create, alter o drop"?

marianogenovese commented 7 years ago

Es posible hacerlo para las fuentes, basado en la metadata. Sql lo hace basado en syscolumns, sysindexes, etc.

OscarCanek commented 7 years ago

Para los streams? (siento que estoy omitiendo algo)

OscarCanek commented 7 years ago

Lo único que se necesita almacenar como texto es la consulta de stream?

marianogenovese commented 7 years ago

Inicialmente si, el stream permanente.