Работа с БД SQLite в тестере
Нужен минимальный код для воспроизведения поведения, иначе сложно понять где нужно копать.
Покопался- разобрался. Все дело в агентах и параллельности расчетов в тестере. Т.е., когда, например, в цикле идет запись в таблицу БД - отправка запросов INSERT построчно, то весь цикл почему то выполняется не одним агентом, а несколькими, соответственно "нет порядка в войсках"- какая то строка под номером k может записаться раньше, чем строка k-1 - это точно есть- это видно, хотя это на результат моей задачи не должно влиять. Но плюс к этому, возможно и скорее всего идет параллельное удаление / создание таблиц БД, а это уже полностью нарушает весь алгоритм.
При работе одним агентом все считается правильно.
Осталось понять возможно ли как то управлять потоком задач для агентов.
Да, при работе с базой используется флаг DATABASE_OPEN_COMMON - это означает, что все агенты работают с одним файлом-базой, отсюда и проблемы из-за асинхронности работы агентов.
Синхронизовать работу локальных агнетов можно, но только через файл в папке COMMON
Можно использовать транзакции https://www.mql5.com/ru/docs/database/databasetransactionbegin
Но, есть вариант получше, использовать https://www.mql5.com/ru/docs/optimization_frames - это позволит собрать данные с агентов в терминале синхронно и уже в терминале сохранить их базу. Кроме того, появится возможность использовать не только локальные, но и удалённые агенты.
- www.mql5.com
Да, при работе с базой используется флаг DATABASE_OPEN_COMMON - это означает, что все агенты работают с одним файлом-базой, отсюда и проблемы из-за асинхронности работы агентов.
Синхронизовать работу локальных агнетов можно, но только через файл в папке COMMON
Можно использовать транзакции https://www.mql5.com/ru/docs/database/databasetransactionbegin
Но, есть вариант получше, использовать https://www.mql5.com/ru/docs/optimization_frames - это позволит собрать данные с агентов в терминале синхронно и уже в терминале сохранить их базу. Кроме того, появится возможность использовать не только локальные, но и удалённые агенты.
Добавьте, пожалуйста, возможность определения индекса для агента. Проще решать вопросы синхронизации
Можно номер порта возвращатьДобавьте, пожалуйста, возможность определения индекса для агента. Проще решать вопросы синхронизации
Можно номер порта возвращатьЭти данные будут доступны, если во фрейм будете добавлять одно из двух.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Может ли советник без DLL функций отправить куда-нибудь данные?
fxsaber, 2017.06.19 16:28
[ 0] "MQLInfoString(MQL_PROGRAM_PATH) = C:\Program Files\Alpari Limited MT5\Tester\Agent-127.0.0.1-3000\MQL5\Experts\Moving Average3.ex5" [26] "TerminalInfo(TERMINAL_DATA_PATH) = C:\Program Files\Alpari Limited MT5\Tester\Agent-127.0.0.1-3000"
Да, при работе с базой используется флаг DATABASE_OPEN_COMMON - это означает, что все агенты работают с одним файлом-базой, отсюда и проблемы из-за асинхронности работы агентов.
Синхронизовать работу локальных агнетов можно, но только через файл в папке COMMON
Можно использовать транзакции https://www.mql5.com/ru/docs/database/databasetransactionbegin
Но, есть вариант получше, использовать https://www.mql5.com/ru/docs/optimization_frames - это позволит собрать данные с агентов в терминале синхронно и уже в терминале сохранить их базу. Кроме того, появится возможность использовать не только локальные, но и удалённые агенты.
Транзакции позволяют изолировать часть манипуляций с БД: вставка и обновление строк. Но на создание / удаление таблиц функции DatabaseTransactionBegin и DatabaseTransactionCommit не действуют.
Кадры - это про сбор статистики с агентов - они также не позволяют изолировать в тестере на одном агенте цепочку операций манипуляций с таблицами (удаление/создание таблицы+добавление строк+селект) без гарантий невнесения изменений от других агентов.
Но я понял, что в целом моя постановка задачи на манипуляцию с одними и теми же данными при использовании в тестере более одного агента - неправильная. Поэтому и ошибки. Надо параллелить: для каждого набора параметров создавать отдельные таблицы, тогда не будет пересечения действия агентов.
Ну и, соответственно, здесь уже встает вопрос о возможности и скорости параллельной обработки запросов движком базы. Но это, понятно- вопрос не по MQL. Вроде как все возможности в SQLite есть. Буду пробовать.
- 2010.10.30
- anand anand 2,339 2 2 gold badges 14 14 silver badges 3 3 bronze badges
- translated.turbopages.org
Помаял еще немного. Как итог могу сказать, что работа в тестере с БД при использовании более, чем одного агента - именно работа с БД: манипуляция с данными (добавление / удаление / отбор данных), а не запись данных тестирования в БД- это неуправляемый процесс, ну либо лыжи у меня не едут.
Это какая то магия- из-за отсутствия возможности обработки обратной связи от БД приходится встраивать задержки. Но даже с задержкой на одних и тех же параметрах оптимизации получаются разные результаты (зависит от того как отработает БД: даст/не даст ответ на запрос).
На одном агенте все работает отлично.
Конечно, можно переносить данные в массивы в MQL и работать в тестере уже с ними, но придется тогда писать реализацию SQL под MQL, а это совсем другая история )). Ведь задача то в том и состоит, чтобы в оптимизаторе подбирать параметры для селектов, а БД уже лучшим образом вернет то, что нужно из бооольших таблиц..
Поэтому два вопроса: 1) есть ли возможность явно изолировать работу агентов: давать им на выполнение определенный набор инструкций. И 2) есть ли возможность получать обратную связь от БД: доступна/нет?
Помаял еще немного. Как итог могу сказать, что работа в тестере с БД при использовании более, чем одного агента - именно работа с БД: манипуляция с данными (добавление / удаление / отбор данных), а не запись данных тестирования в БД- это неуправляемый процесс, ну либо лыжи у меня не едут.
Это какая то магия- из-за отсутствия возможности обработки обратной связи от БД приходится встраивать задержки. Но даже с задержкой на одних и тех же параметрах оптимизации получаются разные результаты (зависит от того как отработает БД: даст/не даст ответ на запрос).
На одном агенте все работает отлично.
Конечно, можно переносить данные в массивы в MQL и работать в тестере уже с ними, но придется тогда писать реализацию SQL под MQL, а это совсем другая история )). Ведь задача то в том и состоит, чтобы в оптимизаторе подбирать параметры для селектов, а БД уже лучшим образом вернет то, что нужно из бооольших таблиц..
Поэтому два вопроса: 1) есть ли возможность явно изолировать работу агентов: давать им на выполнение определенный набор инструкций. И 2) есть ли возможность получать обратную связь от БД: доступна/нет?
В SQLite нет возможности одновременного изменения данных несколькими процессами. Только один процесс в единицу времени может производить изменения данных, остальные процессы должны ждать. Чтение данных могут делать несколько процессов одновременно, но только не тогда, когда происходит изменение данных.
Для организации правильного доступа к БД процессы должны проверять в каком состоянии находится БД. Сделать это можно например через возврат ошибок: ERR_DATABASE_BUSY 5605 Файл базы данных заблокирован, или других. Нужно посмотреть какие ошибки БД возвращаются и в каких состояниях.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Как правильно работать с БД SQLite в тестере?
Получил непонятный результат на простой задаче:
Есть таблица- ряд дат. Интервалы между датами неравномерные.
Делаю функцию, которая на основе первой таблицы создает новую таблицу и по заданному интервалу записывает туда новый ряд дат, уже равномерно расположенных (в диапазоне минимума и максимума первой таблицы). Далее селектом сравниваются эти две таблицы и возвращается количество совпадений.
Далее запускаю в скрипте эту функцию прохожу в цикле по размеру интервалов и получаю цифры совпадений. Функция работает нормально.
Но в тестере (при оптимизации) что то не получается. Работает в разных случаях по разному- на каких то интервалах функция работает (создает новую таблицу и возвращает результат), на других интервалах - не работает. Потом при повторном запуске оптимизации дает правильный результат.
Пришла мысль, что тестер в отличие от скрипта при запуске команд не дожидается их окончания. Приладил задержку, что то стало лучше. Но все-равно точные данные не получаются. ЧЯДН?