Восстановление сохраненной стратегии

У меня тоже подход по позициям, каждый имеет свою долю и это фиксируется.
Может наивно, но так же использую\отображаю график PnL и статистику, вот и для этого и нужны, чтобы отображались корректно. Или это лучше самому считать?

Но в целом я понял, используется AttachOrder и его сделками... этого и хотел

Супер секретная разработка по сохранению/восстановлению стратегий:
[url]http://stocksharp.com/forum/4045/S--Shell--Manual/?page=2

Большое спасибо за ответ. Так как я не программист, мне потребовалось несколько дней, чтобы разобраться в коде
Есть несколько вопросов:
- Ваша идея восстановления позиции состоит в том, чтобы при каждом запуске заново грузить все сделки и по ним считать позицию. Для этого сделки хранятся в БД. Это абсолютно верно, что из сделок можно получить поозицию, но, как мне кажется, избыточно.
Был ли рассмотрен следующий подход: при совершении сделки (partial fill/ full fill), меняется позиция. Робот узнает об изменении позиции только от feedback от биржи о статусе исполненного ордера (ну либо если ордер лимитный, и робот знает, что пришел confirmation о том, что он выставлен, + цена прошла уровень ордера, то автоматом считаем ордер исполненным - нужно для HFT). Так вот, как только робот узнает об изменении позиции, вместо того, чтобы тут же сохранять сделку в БД он просто записывает в файл позицию. При старте робота, не нужно выгружать все сделки, а только сообщить стартовую позицию и все.

- Встает вопрос, за какой период нужно выгружать сделки. Если робот торгует длинные таймфремы, то это может быть и несколько месяцев. А это дофига сделок, если есть в портфеле есть стратегии торгующие high frequency и low frequency.

- В чем потенциальные минусы предложенного подхода в сравнении с уже реализованным выше. Может я упускаю какие-то тонкости?

Тут в каждом подходе есть свои плюсы и свои минусы.

1. Восстановление позиций через восстановление заявок/сделок
Очевидный плюс - получение полноценной статистики и PnL на основе свойств стратегии.
Минус - при большом числе заявок/сделок перфоманс при старте падает.
Кроме того у меня при количестве заявок прим. от 2000 / сделок от 3000 стали возникать проблемы с тем, что предварительный запрос на очистку таблиц от старых записей в целях исключения дублирований стал прерываться при старте следующего по коду запроса на запись, и как результат пошла мультипликация записей. Возможно там для решения проблемы нужно было перейти на асинхронный вызов и дожидаться выполнения первого запроса из кода, но я к этому моменту осознал избыточность для моих интересов данного подхода и остановил запись и восстановление заявок/сделок.
Перешел на подход №2.

2. Восстановление позиций через восстановление информации о позициях
Очевидный плюс - сохранение в БД только самой важной информации.
Далее, если объект заявка содержит только одно поле UserOrderId для хранения информации о сигнале на открытие позиции, то в собственном классе по позициям можно создать несколько полей для последующего использовании при принятии решения о закрытии позиции (н-р сигнал, тайм-фрейм) и подсчете доходов (н-р при торговле фичами размер резерва капитала, даты/спреды ролл-оверов).
Минус - необходимость создания собственного класса для хранения позиций и встраивание его работы в работу стратегии.
Кроме того стандартные статистика и PnL по стратегии теряют свою актуальность. Статистика конечно не столь важна, а вот для расчета PnL пришлось написать отдельную функцию. Для моей стратегии правда это было и так необходимо сделать, так как PnL с учетом колебаний рыночной стоимости не интересен, а интересна мгновенная и общая годовая доходность работы по сигналам.

Поэтому я бы сказал что выбор подхода тут сильно зависит от используемой стратегии. Для относительно простых стратегий с небольшим количеством сделок пойдет и 1й подход, для более сложных конечно удобней сделать свою логику.

Я тоже создал свои классы и под хранение инфы по трейдам (не позициям), а также по правильному подсчету pnl, mark-to-market pnl, доходности и т.д.
Поправь меня если я не прав, но по ссылке выше ты рассказал именно про реализацию подхода 1 - восстановления позиции через сделки.
Тогда вопрос: Как реализовать именно вараинт 2?
По большому счету тут SQL не нужно. Достаточно 1 файл с элементами типа {Strategy ID/Name, Position}. И при перезапуске робота считывать эти данные и сообщать роботу с какой позицией он стартует. Тогда в общем случае и логику менять не надо, так как робот просто сразу переходит в состояние long/short N контрактов как бы пропуская фазу набора позиции.

по большому счету да, сохраняешь состояние стратегии и восстанавливаешь его при создании. Но тогда теряется статистика стратегии... но если у тебя свои классы по ее подсчету, то можно себе позволить

покажешь свои классы "подсчету pnl, mark-to-market pnl, доходности и т.д." ?

А что мешает взять из БД позицию/ордера/сделки по последней открытой позиции, а сохраненные данные по предыдущим сделкам/позициям/ордерам использовать для анализа работы системы?

В данном топике это оффтоп. На самом деле, я даже классы не делал. На каждом тике пересчитываю стоимость позиции (== mark to market), из этого получается и pnl при закрытии позиции (реализованный mark to market) и доходность (pnl/capital)

Я не понял, как можно передать роботу позицию? AttachOrder функция есть, а как указать текущую позицию при старте?