Ejecutar consultas sin enlace de datos MQL5

Algunas consultas SQL son comandos que basta con enviar al motor tal cual. No requieren ni entrada de variables ni resultados. Por ejemplo, si nuestro programa MQL necesita crear una tabla, índice o vista con una determinada estructura y nombre en la base de datos, podemos escribirlo como una cadena constante con la sentencia «CREATE...». Además, es conveniente utilizar este tipo de consultas para el tratamiento por lotes de registros o su combinación (fusión, cálculo de indicadores agregados y modificaciones del mismo tipo). Es decir, con una sola consulta, puede convertir los datos de toda la tabla o rellenar otras tablas basándose en ella. Estos resultados pueden analizarse en las consultas posteriores.

En todos estos casos, sólo es importante obtener la confirmación del éxito de la acción. Las solicitudes de este tipo se realizan mediante la función DatabaseExecute.

bool DatabaseExecute(int database, const string sql)

La función ejecuta una consulta en la base de datos especificada por el descriptor database. La propia solicitud se envía como una cadena lista sql.

La función devuelve un indicador de éxito (true) o de error (false).

Por ejemplo, podemos complementar nuestra clase DBSQLite con este método (el descriptor ya está dentro del objeto).

Entonces el script que crea una nueva tabla (y, si es necesario, previamente, la propia base de datos) puede tener este aspecto (DBcreateTable.mq5):

Después de ejecutar el script, intente abrir la base de datos especificada en MetaEditor y asegúrese de que contiene una tabla vacía con un único campo de texto «msg». Pero también puede hacerse mediante programación (véase la sección siguiente).

Si ejecutamos el script por segunda vez con los mismos parámetros, obtendremos un error (aunque no crítico, sin forzar el cierre del programa).

Esto se debe a que no se puede volver a crear una tabla existente. Pero SQL permite suprimir este error y crear una tabla sólo si aún no existe, de lo contrario, permite no hacer casi nada y devolver un indicador de éxito. Para ello, basta con añadir «IF NOT EXISTS» delante del nombre en la consulta.

En la práctica, las tablas son necesarias para almacenar información sobre objetos del área de aplicación, como cotizaciones, operaciones y señales de trading. Por lo tanto, es deseable automatizar la creación de tablas basadas en la descripción de objetos en MQL5. Como veremos más adelante, las funciones SQLite ofrecen la posibilidad de vincular los resultados de las consultas a estructuras MQL5 (pero no a clases). En este sentido, en el marco del envoltorio ORM, desarrollaremos un mecanismo para generar la consulta SQL «CREATE TABLE» de acuerdo con la descripción struct del tipo específico en MQL5.

Para ello es necesario registrar de algún modo los nombres y tipos de los campos de estructura en la lista general en el momento de la compilación y, a continuación, ya en la fase de ejecución del programa, se pueden generar consultas SQL a partir de esta lista.

En la fase de compilación se analizan varias categorías de entidades MQL5, que pueden utilizarse para identificar tipos y nombres:

• macros
• herencia
• plantillas

En primer lugar, hay que recordar que las descripciones de los campos recopilados están relacionadas con el contexto de una estructura concreta y no deben mezclarse, porque el programa puede contener muchas estructuras diferentes con nombres y tipos potencialmente coincidentes. En otras palabras: es deseable acumular información en listas separadas para cada tipo de estructura. Para ello es ideal un tipo de plantilla cuyo parámetro (S) será la estructura de la aplicación. Llamemos a la plantilla DBEntity.

Dentro de la plantilla hay un array multidimensional prototype, en el que escribiremos la descripción de los campos. Para interceptar el tipo y el nombre del campo aplicado, tendrá que declarar otra estructura de plantilla, DBField, dentro de DBEntity: esta vez su parámetro T es el tipo del propio campo. En el constructor, tenemos información sobre este tipo (typename(T)), y también obtenemos el nombre del campo (y opcionalmente, la restricción) como parámetros.

El campo f no se utiliza, pero es necesario porque las estructuras no pueden estar vacías.

Supongamos que tenemos una estructura de aplicación Data (DBmetaProgramming.mq5).

Podemos hacer que su análogo heredado de DBEntity<DataDB>, pero con campos sustituidos basados en DBField, sea idéntico al conjunto original.

Al sustituir el nombre de la estructura en el parámetro de la plantilla padre, la estructura proporciona al programa información sobre sus propias propiedades.

Preste atención a la definición única de la variable proto junto con la declaración de la estructura. Esto es necesario porque, en las plantillas, cada tipo parametrizado específico sólo se compila si se crea al menos un objeto de este tipo en el código fuente. Es importante para nosotros que la creación de este proto-objeto se produzca al principio del lanzamiento del programa, en el momento de la inicialización de las variables globales.

Una macro se oculta bajo el identificador DB_FIELD:

Así es como se expande para un solo campo:

Aquí la estructura no sólo se define, sino que se crea al instante: de hecho, sustituye al campo original.

Dado que la estructura DBField contiene una única variable f del tipo deseado, las dimensiones y la representación binaria interna de Data y DataDB son idénticas. Esto puede comprobarse fácilmente ejecutando el script DBmetaProgramming.mq5.

Éste envía al registro lo siguiente:

Sin embargo, para acceder a los campos, tendría que escribir algo inconveniente: data._long_id.f, data._string_name.f, data._datetime_timestamp.f, data._double_income.f.

No lo haremos, no sólo y no tanto por inconveniencia, sino porque esta forma de construir metaestructuras no es compatible con los principios de vinculación de datos a consultas SQL. En las siguientes secciones exploraremos las funciones de database que permiten obtener registros de tablas y resultados de consultas SQL en estructuras MQL5. No obstante, sólo se permite utilizar estructuras simples sin herencia y miembros estáticos de tipos de objeto. Por lo tanto, es necesario modificar ligeramente el principio de revelación de la metainformación.

Tendremos que dejar sin cambios los tipos de estructuras originales y repetir de hecho la descripción para la base de datos, asegurándonos de que no haya discrepancias (erratas). Esto no es muy conveniente, pero no hay otra manera en este momento.

Trasladaremos la declaración de instancias DBEntity y DBField más allá de las estructuras de aplicación. En este caso, la macro DB_FIELD recibirá un parámetro adicional (S), en el que será necesario pasar el tipo de la estructura de la aplicación (antes se tomaba implícitamente declarándolo dentro de la propia estructura).

Dado que las columnas de la tabla pueden tener restricciones, también habrá que pasarlas al constructor de DBField si es necesario. Para ello, vamos a añadir un par de macros con los parámetros adecuados (en teoría, una columna puede tener varias restricciones, pero normalmente no más de dos).

Las tres macros, así como otros desarrollos, se añaden al archivo de encabezado DBSQLite.mqh.

Es importante tener en cuenta que esta vinculación «propia» de los objetos a una tabla sólo es necesaria para introducir datos en la base de datos, ya que la lectura de datos de una tabla a un objeto se implementa en MQL5 mediante la función DatabaseReadBind.

Mejoremos también la aplicación de DBField. Los tipos MQL5 no se corresponden exactamente con las clases de almacenamiento SQL, por lo que es necesario realizar una conversión al rellenar el elemento prototype[n][0]. Para ello se utiliza el método estático affinity.

Las constantes de texto de los tipos genéricos SQL utilizados aquí se colocan en un espacio de nombres separado: pueden ser necesarios en diferentes lugares en los programas MQL en algún momento, y es necesario asegurarse de que no hay conflictos de nombres.

Los preajustes de las posibles restricciones también se describen en su grupo para mayor comodidad (a modo de pista).

Dado que algunas de las restricciones requieren parámetros (los lugares para ellos están marcados con el modificador de formato habitual «%s»), añadamos una comprobación de su presencia. Esta es la forma final del constructor DBField.

Debido a que la combinación de macros y objetos auxiliares DBEntity<S> y DBField<T> rellena un array de prototipos, dentro de la clase DBSQlite, se hace posible implementar la generación automática de una consulta SQL para crear una tabla de estructuras.

El método createTable se modela con un tipo de estructura de aplicación y contiene un stub de consulta («CREATE TABLE %s %s (%s);»). Su primer argumento es la instrucción opcional «IF NOT EXISTS». El segundo parámetro es el nombre de la tabla, que por defecto se toma como el tipo del parámetro de plantilla typename(S), pero se puede sustituir por otra cosa si es necesario utilizando el nombre del parámetro de entrada (si no es NULL). Por último, el tercer argumento entre paréntesis es la lista de columnas de la tabla: la forma el método de ayuda columns a partir del array DBEntity <S>::prototype.

Para cada columna, la descripción consta de un nombre, un tipo y una restricción opcional. Además, es posible pasar una restricción general a la tabla (table_constraints).

Antes de enviar la consulta SQL generada a la función DatabaseExecute, el método createTable produce una salida de depuración del texto de la consulta al registro (toda salida de este tipo en las clases ORM puede desactivarse de forma centralizada sustituyendo la macro PRTF).

Ahora todo está listo para escribir un script de prueba DBcreateTableFromStruct.mq5, que, por declaración de estructura, crearía la tabla correspondiente en SQLite. En el parámetro de entrada, establecemos sólo el nombre de la base de datos, y el programa elegirá el nombre de la propia tabla en función del tipo de estructura.

En la función principal OnStart, creamos una tabla llamando a createTable con la configuración predeterminada. Si no queremos recibir una señal de error cuando intentemos crearlo la próxima vez, tenemos que pasar true como primer parámetro (db.createTable<Struct> (true)).

El método hasTable comprueba la presencia de una tabla en la base de datos por el nombre de la tabla. Examinaremos la aplicación de este método en la sección siguiente. Ahora, vamos a ejecutar el script. Tras la primera ejecución, la tabla se crea correctamente y puede ver la consulta SQL en el registro (se muestra con saltos de línea, tal y como la formamos en el código).

La segunda ejecución devolverá un error de la llamada a DatabaseExecute, porque esta tabla ya existe, lo que se indica adicionalmente en el resultado de hasTable.