English
Русский
中文
Español
Português
日本語
И так, предлагаю подытожить то, что нужно сделать и в каком порядке.
Задачи сгруппировал по группам (копировал из соседней ветки http://stocksharp.com/forum/1275/&p=2). Первая группа - самая приоритетная. Без нее делать задачи из следующей бессмысленно. Сами задачи внутри этой группы так же выстроены по очередности.
Базовая группа:
- Описать основные метаданные, как это сделано для Квика (DdeSecurityColumns, DdeTradeColumns и т.д.). Я это уже показал на примере класса PlazaFutureColumns, но там колонки не реальные. Предлагаю прямо разобрать по названию таблиц потоков, кто за какие будет отвечать (описывать в коде). Таблицы только основные: инструменты, заявки, сделки и т.д.
- Подписываться на произвольные потоки + отписываться.
- Получать стаканы. Производная от предыдущей задача. Выделил ее отдельно.
- Заявки (регистрация, снятие и перемещение). Я уже сделал через класс Message заполнение полей для отправки транзакций. Это дело надо доделать.
- Парсинг ответа от транзакций (внимание! всех транзакций, а не только, что в предыдущем пункте). Я не знаю, в каком виде они приходят, но могу сказать, какой результат должен быть. Это должно быть PlazaException с кодом ошибки (чтобы не мучится сравнение строчек в коде). И код не ввиде числа (что не так уж лучше строчки), а нормального перечисления (enum).
Первую задачу предлагаю сделать сообща. Остальные - разбираем по тем признакам, кто какие таблицы описывал (например, кто описал стакан, тот занимается задачей 3, кто инструменты - задачей 2, кто заявки - задачей 4).
Второстепенная группа:
- Дописать все остальные метаданные (позиции, счета, волатильность, маржа, клиринг, доп информация о деривативах, индексы).
- Фильтрация потоков. Так как Плаза не дает фильтр (камрад skuvv написал об этом), но в клиентском коде прописывать фильтры дело не благодарное, предлагаю это симулировать через RegisterXXX + UnRegisterXXX.
- Возможность задавать глубину стакана (как я понял, это влияет на то, к какому потоку необходимо цепляться).
- Поддержка агрегированного стакана и обычного. Для этого можно использовать GroupedQuote (внутри себя он будет содержать не агрегированные котировки).
Третьестепенная группа:
- С помощью метаданных научиться строить конфиги ini. Как вариант, через PlazaTable (куда собственно и будут добавляться колонки из пункта 1 пред группы). Сейчас ini файлы программно редактировать нельзя. И если роботу нужны спец колонки нужно менять формат ini схем. Я предлагаю до загрузки этих схем давать возможность менять из программно (парсить и менять ini файлы на лету). + как фича автоматически сканировать директорию при старте и создавать с правильным набором колонок сами PlazaTable. Возможно, здесь поможет TableSet.
- Время биржи.
- Все остальные транзакции (FutChangeClientMoney, OptChangeExpiration и т.д.).
- Составные инструменты.
- На форуме доступна x64 версия. Нужна прозрачная поддержка (без перекомпиляции) x86 и x64.
- Обертка над роутером (чтобы так же, не ручками править конфиги, а программно).
- Документация (как xml, так и обычная). Если нужно сделать как у S#, то необходимо использовать Sandcastle.
Особенности в работе.
Старайтесь писать так, как это принято в .NET и в частности C# коде. Публичные методы классы и т.д. описывайте xml комментариями (лучше не сочинять, а копировать из документации Плазы, чтобы быть не с планеты Юпитер, а ближе к тем, кто будет это использовать и вторым глазом подглядывать в документацию). Предлагаю использовать R# как средство для контроля качества кода. Пишите юнит тесты (заведите отдельный проект в sln).
Kommentare (78)
Anmelden oder Konto erstellen, Melden Sie sich an oder registrieren Sie sich, um einen Kommentar zu hinterlassen
А где посмотреть PlazaFutureColumns? Всех с Новым Годом!
Приехали. Я же доступ дал к ТФС и Вы написали, что успешно подключились. Там лежит то, что я начинал по Плазе. В том числе и данный класс.
Михаил, на эту тему у нас уже была переписка. Я: "Но тут новая проблемка нарисовалась. В студии командный проект (папка 1.0) пустым выглядит. Встроен ли Teamprise Explorer в студию 2010, или его надо отдельно скачать и инсталлировать? Если первое, то как он называется в русскоязычной версии? Если же это и есть командный обозреватель в новой версии безо всяких рычагов, то в нём-то и пусто". Вы: "Не туда смотрите. Исходники в другом месте". В итоге я смотрю: 1) не так; 2) не там; или 3) не то?
Я в инструкции давал ссылку на доку по TFS. Прочтите, там не много, лишним не будет.
Как будем сообщать о загрузке файлов, выполнении задач? Только что загрузил три файла, связанные с настройкой конфиг-файла роутера.
Комменты в самом TFS + отпишите на форум.
И так, праздники прошли, логинов роздано с двух десятков, задачи есть, план по задачам есть (по крайней мере никто не высказывался против, впрочем как и за). Предлагаю разбирать задачи. Как я уже написал, первую задачу можно сделать сообща. Это будет своеобразной пионерской задачей и сразу покажем, как нужно координировать действия.
Трублю всеобщий сбор.
Предлагаю взять Поток FORTS_OPTTRADE_REPL - Опционы: заявки и сделки
Таблицы: • orders_log - Журнал заявок • deal - Журнал сделок • heartbeat - Служебная таблица cерверных часов
Я беру FORTS_FUTINFO_REPL - Фьючерсы: справочная и сессионная информация. Только то, что относиться к инструментам и сессиям:
Так, а что с остальными? Нужно как в школе называть всех по списку?
Я сделал несколько чекинов, чтобы структурировать первоначальное (+ сделать компилируюемым).
если всё свободно то FORTS_FUTTRADE_REPL - Фьючерсы: заявки и сделки
Таблицы: orders_log - Журнал заявок deal - Журнал сделок multileg_orders_log - Журнал заявок по связкам multileg_deal - Журнал сделок по связкам heartbeat - Служебная таблица cерверных часов
я так понимаю orders_log, deal и heartbeat первоочередные, остальные могут потерпеть.
По мне так и multi может подождать. Но если есть желание все сделать сразу, почему бы нет.
Михаил,
Прочитав ваше сообщение, понял, что мне нужно начать с
Поток FORTS_OPTINFO_REPL - Опционы: справочная и сессионная информация Схема данных Таблицы: • opt_exp_orders - Заявки на экспирацию • opt_vcb - Справочник торгуемых активов • opt_sess_contents - Cправочник торгуемых инструментов • opt_sess_settl - Результаты клиринга: волатильность и теоретические цены
Ок, тогда буду смотреть на ваши чекины, так как у нас могут метаданные пересекаться. Например, вряд ли опционная сессия чем-то отличается от фьючерсной. Давайте сделаем так. Все, что вы думаете относиться к деривативам вообще (фьючи опшины) - выносите не в класс PlazaOptionЧтотоТам, а в PlazaDerivativeЧтотоТам (если его еще нет, то надо создать).
Михаил,
Создал класс PlazaDerivativeColumns, который будет использоваться для справочников базовых контрактов для инструментов (fut_vcb, opt_vcb).
Вопрос по реализации: сейчас в классе PlazaFutureColumns колонки - это открытые статические переменные для чтения, а, например, в классе DdeSecurityColumns колонки - открытые статические свойства только для чтения. Прописываем колонки, как переменные? Интереса ради, с чем связано такое изменение?
Добавил класс PlazaDerivativeColumns
Описывает колонки справочники базовых контрактов для инструментов Поток FORTS_FUTINFO_REPL - таблица fut_vcb Поток FORTS_OPTINFO_REPL - таблица opt_vcb
Просьба указывать комментарий при чекине. Есть такое поле вверху в окне Checkin changed.
Дополнительно, замените в студии пробелы на табы. Навигация по коду стрелками усложняется.
Сделал разъединение PlazaDerivativeColumns на PlazaFutureColumns и PlazaOptionColumns. PlazaDerivativeColumns теперь абстрактный, и статические поля убраны. Тоесть, вместо написания myTable.Columns.Add(PlazaDerivativeColumns.ClientCode) теперь будет myTable.Columns.Add(PlazaColumns.Futures.ClientCode).
Вопрос. А почему классы в проектный файл csproj не добавляете?
добавил таблицу Common для FORTS_FUTCOMMON_REPL ps таблица совпадает с таблицей их потока FORTS_OPTCOMMON_REPL
Ок. Такие же просьбы как и к аспиранту. Плюс, посмотрите как я переделал PlazaPosColumns (вынес общие поля в базовый класс + сделал поля не статичными).
Понял, приму к сведению.
добавил таблицу orders_log из FORTS_FUTTRADE_REPL. наследовал от PlazaColumns
PS Таблица совпадает с orders_log из FORTS_OPTTRADE_REPL (отличие в том что для опционов поле status может принимать ещё 2 дополнительных значения)
PPS Первый опыт работы в команде и с TFS - ногами не бить.🙄
PPPS как изменить платформу с 4.0 на 3.5? Найти в VS2010 у меня не получилось. 🤨
В свойствах проекта на закладе Приложение / Application
Спасибо!
Описал метаданные по опционам. Вопрос к знающим: нужно описывать таблицу opt_rejected_orders - Отвергнутые в клиринг заявки?
добавил таблицу deal из FORTS_FUTTRADE_REPL
PS Таблица совпадает с deal из FORTS_OPTTRADE_REPL (опять отличие в разных вариантах значений поля status)
таблица heartbeat из FORTS_FUTTRADE_REPL уже существует в виде PlazaHeartBeatColumns, собственно её не описываю.
добавил таблицы multileg_deal и multileg_orders_log из FORTS_FUTTRADE_REPL
Надо бы произвести уже сейчас чистку некоторых вещей. Отпишу здесь по названию классов, кто за них ответственен - разбирайте. Но прочитайте все пункты, так как может быть и у вас так же.
PlazaFutCommonColumns:
PlazaFutTradeDealColumns, PlazaFutTradeMultilegDealColumns, PlazaFutTradeMultiLegOrdersLogColumns, PlazaFutTradeOrdersLogColumns:
PlazaHeartBeatColumns
Насчет общего стиля именования. Предлагаю, писать полностью имена, тоесть:
OrdId -> OrderId SessId -> SessionId Dir -> Direction
Название ISIN можно писать как ISIN, Isin, но никак не IsIn. Аббревиатуры (в данном случае International Securities Identification Number) так не пишутся.
Предлагаю не писать тип данных в комментариях к поля (i) (t) и т.д.. Добавляет лишнюю смысловую нагрузку, которая по сути вряд ли будет использоваться из вне.
Названия я предлагаю не менять, а дописывать до полного... В любом случае, будет много, что не как в стандартном АПИ. Но нужно одновременно сделать удобным и работу с документацией Plaza, и дальнейшей работой с роботом. Мне кажется, что документация по Плазе нужна только в первое время. В дальнейшем видеть в коде названия ordid sessid и т.д. не очень приятно. Но это только мое мнение.
исправил
Изначально при именовании переменных я хотел сохранить близость к оригиналу, на случай если кому-то придется работать с документацией самой Плазы. Сейчас понимаю, что читаемость кода, пожалуй, важнее. Тем более что я сам себе противоречил, обозвав классы полными именами, например, PlazaOptionSessionContentsColumns, а не PlazaOptSessContentsColumns.
Насчет IsIn'а я ступил. Предлагаю Isin, потому что, во-первых, кроме Isin'а еще будет переменная IsinId, а во-вторых, это в духе .Net'а, см. System.Xml.
Пожалуй, это действительно был перебор, сейчас исправлю
вроде всё.
Все исправил. Не знаю только, как правильно именовать:
/// <summary> /// Базовое ГО под одну покрытую позицию подписчика (руб) /// </summary> public readonly PlazaColumn bgo_c = new PlazaColumn(PlazaTableTypes.Option, "bgo_c", typeof(decimal), true);
/// <summary> /// Базовое ГО под одну непокрытую позицию подписчика (руб) /// </summary> public readonly PlazaColumn bgo_nc = new PlazaColumn(PlazaTableTypes.Option, "bgo_nc", typeof(decimal), true);
Главное, не с маленькой буквы, и_убрать_подчеркивания. BgoC, BgoNc. Вполне сойдет.
Еще вопрос. Что делать с этими переменными?
/// <summary> /// Дата окончания обращения инструмента /// </summary> public readonly PlazaColumn DPG = new PlazaColumn(PlazaTableTypes.Option, "d_pg", typeof(DateTime), true);
/// <summary> /// Дата начала экспирации инструмента /// </summary> public readonly PlazaColumn D_Exec_Beg = new PlazaColumn(PlazaTableTypes.Option, "d_exec_beg", typeof(DateTime), true);
/// <summary> /// Дата окончания экспирации инструмента /// </summary> public readonly PlazaColumn D_Exec_End = new PlazaColumn(PlazaTableTypes.Option, "d_exec_end", typeof(DateTime), true);
Решарпить плазовские названия? Или писать что-то типа:
d_pg: ExerciseDate d_exec_beg: ExpirationStartDate d_exec_end: ExpirationEndDate
Если мы за читаемость, я все-таки предлагаю второй вариант
Как они сами в таком ужасе разбираются?
Согласен.
Готово
Я так понимаю, задачу 1 не только выполнили, но и перевыполнили? Тогда корректируем задачи в зависимости от силы исполнения. Те, кто хочет остаться на метаданных, пусть дописывает оставшиеся. Только перед этим надо написать здесь, какие именно таблицы хочется дописать, чтобы не получилось дублирования работы.
Далее, задачи с 2 по 5. Задачи 2 и 3 мне кажется схожи. Поэтому, предлагаю стаканы отложить до тех пор, пока не будет закончена задача 2. Если так окажется, что желающих больше чем задач (вряд ли, но все же), то предлагаю спуститься к задачам из третьестепенной группы (второстепенные задачи слишком тесно связаны с первостепенными).
Схема стандартная - пишем кто-что хочет делать и делаем.
В принципе по опционам за исключением стаканов описал все. Хотел бы перейти к п. 2
смотрю в сторону п.4
Тогда я п5.
Буду доделывать метаданные... Добавил FORTS_OPTORDERBOOK_REPL и FORTS_FUTORDERBOOK_REPL. update: FORTS_FUTTRADE_REPL - orders_log FORTS_FUTTRADE_REPL - multileg_orders_log FORTS_OPTTRADE_REPL - orders_log Привел к использованию одного базового класса. Есть косяк почти во всех мета - типа поля i8, это не int, a int64, за 32бита перевалило еще в декабре... Есть предложение:
А в чем косяк? На C# есть эквивалент - long.
Не забывайте про комментарии в коммите.
Я везде указывал эти данные (i8), как int. Буду исправлять.
Поддерживаю.
Михаил,
Только что добавил класс PlazaStream. Это пока сырой вариант, потому что есть несколько неразрешенных вопросов. Поскольку логики много, я выделил класс в отдельный файл (я знаю, что вы уже создали приватный класс DerivativeStreams). Потом окончательную версию можно будет поместить, куда нужно.
Сначала комментарий: реализация алгоритма получения данных (метод Run) навеян примером BaselessClient, который шел вместе с тестовой версией Плазы.
Предложения:
Вопросы:
DerivativeStreams мне кажется подобием PlazaColumns, тоесть контейнер всех доступных стримов. Так что в логике пересечения не должно быть.
Мы уже убедились, какого уровня программисты работают в РТС. Так что не стоит равняться на них, даже если речь идет о примерах.😀
Что касается реализации, то могу сказать следующее. PlazaStream не должен содержать логики по управлению потоком (thread, и далее по тексту, чтобы не была путаница с потоками данных РТС, которые stream). В нем вообще не должно быть создание никаких потоков. В идеале у него должны быть пару методов Open Close, и события о получении новых данных, удалении, ошибке и т.д. А вот уже управлять стримами (в том числе и создавать единый поток для обработки всех стримов) нужно в PlazaTrader.
Какие классы внутри проекта будут пользователем класса PlazaStream и в каком виде им нужно выдавать данные (по одной записи или сразу массив записей и т.д.)? Данные приходят в событиях StreamDataInserted / StreamDataDeleted, где есть параметр типа CP2Record, который содержит значения одной записи таблицы.
Лучше стандартные, которые в .NET. Честно говоря я не помню случаем, когда бы использовал другие исключения, вместо ArgExp, ArgOutExp, ArgNullExp, InvOptExp. Все остальные какие-то натянутые, и далекие от простых будней. Разделения на внешний и внутренний не понял.
А вот тут не могу сказать. Как удобнее, так и надо. Тоесть Плаза за раз отсылает только одну строчку?
Дело в том, что работа с плазовским стримом построена по принципу windows message loop: в неком методе программа вызывает метод CP2ConnectionClass.ProcessMessage(out cookie, PollInterval) в бесконечном цикле, а вся информация приходит через события. Если выводить создание и управление thread'ами, это нужно делать в отдельном классе. Иначе, если придется подключаться к стримам в нескольких местах, придется дублировать много кода.
Насчет Name вы правы - уберу. По поводу множественного числа: рекомендация MS - енумераторы в множественном числе, только если они битовые флаги, поэтому все-таки настаиваю на единственном.
Я помню о настраиваемости. Пока в черновом варианте я передаю путь к файлу, чтобы сразу можно было протестировать логику подключения, опроса, получения сообщений и т.д.
С метаданными такая вещь: стримы в Плазе настраиваются из файлов, даже по умолчанию (методы TableSet.InitFromIni / TableSet.InitFromIni2). Если передавать классу PlazaStream в конструкторе PlazaTable, тогда внутри PlazaStream некий класс TableConfigParser должен будет генерить файл с нужной схемой, чтобы передать ее TableSet.InitFromIni. Здесь такой момент: предлагаю в SpecialFolder.ApplicationData создать путь Stocksharp\PlazaTrader\Scheme, в котором хранить свои конфиг-схемы-файлы или их создавать в папке TEMP. Создавать их в подпапке самой Плазы не стоит: требуется админский доступ.
Сделаю
Чтобы понимать в будущем, в каких случаях мы выкидываем PlazaException?
Насколько я понял, есть два варианта:
На мой взгляд вызовы GetValAsХХХ(string fieldName) / GetValAsХХХByIndex(uint fieldIndex) нужно реализовать внутри PlazaStream, а мне чтобы дальше писать это класс нужно понимать:
И последнее насчет фильтрации данных в потоке. Есть предложение это тоже сделать внутри PlazaStream. Тогда при конвертации данных с помощью GetValAsХХХ() / GetValAsХХХByIndex() можно будет проверять только колонки, по которым идет фильтрация, и, если запись не подходит, не выдавать ее клиентскому коду.
Дубляж - это плохо. И плохо, когда стрим создает потоки (кол-во потоков не должно расти с количеством стримов). Плохо делать системный класс слишком уж умным. Код должен быть один и чтобы он управлял всеми стримами.
В папке самого плаза шлюза вообще лучше ничего не править. По умолчанию лучше создавать пути в текущем каталоге (я думаю большинству этого будет достаточно). Плюс сделать путь настраиваемым. Вообщем, логика мне виделась такая (если такое невозможно, то поправьте):
Только когда приходит плазовская ошибка (заявки, потоки или еще что).
Одна особенность, все форматирование лучше помещать в PlazaFormatter. Потому как он уже используется для .NET -> Plaza при отправке транзакций. Не плохо было бы туда поместить и обратную трансформацию.
Насчет оптимизации согласен, но опять получается ситуация со слишком умным PlazaStream.
Вчера разбирался со схемами таблиц потоков. Хочу выложить мои соображения:
В класс PlazaStream в конструкторе нужно будет передавать PlazaTable вместо четырех параметров: потока репликации, схемы репликации, названия таблицы и пути к конфиг-файлу.
Для PlazaTable я напишу PlazaTableSerializer на основе Ecng.Serialization.ISerializer, который будет сохранять/считывать данные в родном формате Плазы. Таким образом PlazaStream при помощи PlazaTableSerializer будет создавать временный конфиг-файл из переданного PlazaTable и с помощью этого конфига инициализировать CP2DataStreamClass.TableSet.
В связи с этим есть пара нюансов:
Да, с точностью получился косяк. Надо исправлять.
skuvv, вы все еще на метаданных? Тогда не пропустите момент, который указал aspirant.
Круто😀. Я только собрался писать об этом изменении. Даже сам еще свои таблицы не исправил.
Этап 2 (опционально): создание таблиц PlazaTable кодом клиента (либо нужный набор колонок, либо все) + наш код парсит все ini файлов в заданной директории для создании на их основе таблиц PlazaTable (через метод PlazaTableSerializer.Deserialize(string fileName) + отслеживаем изменения/добавления файлов в этой директории. Здесь, кстати, уточнение: в предыдущем посте я был не прав. вот, что написано в документации (P2ClientGate.doc стр. 18): "Клиент также может не указывать никакой схемы при открытии потока, в этом случае сервер будет отдавать все данные, которые публикуются в потоке (далее этот режим будет называться «получение данных по схеме сервера»)." Т.е., если в потоке несколько таблиц, будут выдаваться данные по всем таблицам.
Для управления стримами (PlazaStream) я создам PlazaStreamManager, который будет внутри себя создавать стримы, подписываться на их события и управлять их подключением / отключением (т.е. внутри него будет бесконечный цикл). В PlazaStreamManager код пользователя передает коллекцию таблиц (по одной или сразу IEnumerable<PlazaTable>) из предыдущего пункта.
Этап 3 (PlazaTrader.Connect): если в PlazaStreamManager есть стримы, запускаем его. Все стримы будут вертеться в одном потоке (thread). Как дополнительную опцию (третьестепенная / четвертостепенная задача), добавить возможность создания приоритетных стримов в отдельном потоке (thread). Не знаю, нужно ли это?
Насколько я понял, принцип работы со стримами в Плазе следующий: создаем и инициализируем CP2DataStream, затем CP2TableSet (у каждого стрима только один CP2TableSet). Далее подписываемся на события, открываем стрим. После "рукопожатия" (StreamLifeNumChanged) приходит событие StreamDataBegin - данные пошли. Они идут через StreamDataInserted по одной строке. Когда некий объем данных заканчивается, приходит StreamDataEnd. Мне интересно, как часто Plaza выдает событие StreamDataEnd. Хочу в ближайшие пару дней запустить какую-нибудь тестовую программу на пару часов и посмотреть. Если прерывания случаются часто, то действительно можно копить строки (записи) в PlazaStreamManager и выдавать клиенту, например, DataTable или DataRow[] и т.д. Вместе с этим, мне кажется, нужно дать возможность клиенту тоже получать наш вариант StreamDataInserted, тем более что кроме него там еще есть StreamDataUpdated и StreamDataDeleted. В этих событиях можно через PlazaFormatter конвертировать данные в .Net'овские, помещать их в List<object> и выдавать последний клиенту, как object[].
Последнее, насчет фильтрации. Можно будет предусмотреть некий интерфейс IPlazaFilter с методом bool Validate(CP2Record rec, + что-нибудь еще). В методе PlazaStreamManager, который создает новый стрим, можно передавать IEnumerable<IPlazaFilter> или null, который будет привязываться к конкретному стриму. Тогда PlazaStreamManager будет перебирать для каждого стрима его IEnumerable<IPlazaFilter> в событиях StreamDataInserted / StreamDataUpdated / StreamDataDeleted, и если какой-то IPlazaFilter возвращает false, не выдавать событие с данными клиенту.
Только что залил изменения. Хотел поделиться промежуточными итогами:
Исключения нужно перехватывать как можно выше. Кто будет вызывать Close, тот пусть и этим занимается. А так ошибка просто проглотиться.
_dataStream.TableSet.set_rev(plazaTable.Name, _currentRevision++);
_dataStream.TableSet.rev[plazaTable.Name] = _currentRevision++;
Увидел такую подписку:
Она плоха тем, что при таком подписывании нельзя будет отписаться от события и объект будет продолжать висеть в памяти (не так страшно при существующих гигабайтах, но все же). Лямбда выражения создают "на лету" метод обработчик, от которого потом не отписаться. Чтобы производить правильное освобождение ресурсов, нужно от них отказать вообще и писать по старинке:
Я думаю, лучше сразу проговорить для чего вообще нужны лямбда. Они появились тогда, когда в .NET начал входить функциональный стиль. Для этого и только для этого их и придумали (явный пример - это LINQ). Я в своих примерах использовал лямбду не потому что так правильно. А потому что мне было лень писать правильно, и быстрее + короче написать как это сделали Вы. Но внутри S# я так конечно же не делаю, к чему призываю делать и в ПлазаТрейдере.😂
try { _dataStream.Close(); } catch (System.Runtime.InteropServices.COMException e) { // Исправить обработку исключения System.Diagnostics.Trace.WriteLine("Exception {0:X}: {1}".Put(e.ErrorCode, e.Message)); }
исправлю.
Иерархия данных в потоках репликации: ReplicationStream -> ReplicationScheme -> Table -> Field, т,е. у каждой плазовской таблицы (в PlazaTrader это PlazaColumns) есть только одно значение ReplicationStream и ReplicationScheme, поэтому я и счел нужным добавить эти поля в PlazaColumns, чтобы при создании PlazaStream значения ReplicationStream и ReplicationScheme можно было вычислить из PlazaColumns.
Есть два варианта получения данных репликации. Во-первых, можно передать Плазе полный или урезанный набор полей какой-то таблицы (создавать "свои" таблицы с полями из нескольких таблиц нельзя). Второй вариант запроса данных - без указания схемы (см. P2ClientGate.doc стр. 18: "Клиент также может не указывать никакой схемы при открытии потока, в этом случае сервер будет отдавать все данные, которые публикуются в потоке (далее этот режим будет называться «получение данных по схеме сервера»)". Поскольку такой вариант подключения существует, я предусмотрел второй конструктор PlazaStream, в котором только передается ReplicationStream. При таком подключении при получении данных через события нужно будет проверять название таблицы, именно поэтому у CP2DataStreamClass второй параметр событий StreamDataInserted, StreamDataUpdated и StreamDataDeleted - это string tableName.
AddStream(string key, PlazaColumns schema, IEnumerable<PlazaColumn> columns) я исправлю на AddStream(string key, PlazaTable plazaTable)
plazaStream.DataBegin += (p) => OnPlazaStreamDataBegin(key, p);
Это пока временный вариант, потому что я пока еще не определился с окончательным набором параметров событий. По ходу написания добавил string key, а поскольку хотелось залить первый черновой вариант, оставил как есть.
Свои делегаты я убрал вообще. Вы правы, они лишние. Все вызовы событий передал через SafeInvoke.
Кстати, только что заметил, что мой PlazaRtsIndexColumns дублируется с PlazaIndexColumns. Сейчас удалю свое детище😢
А csproj до сих пор на него ссылается. Коммитить нужно все атомарно.
Добавил класс с кодами ошибок плазы - PlazaErrors парсит код ошибки и возвращает текст ps ктото начал заниматься ошибками - пользуйтесь
Я этим занимаюсь😊. Но пока нет времени доделать, так что большое спасибо, что помогли. Но раз уж сделали, вот и Вам code review:
Михаил,
Вопрос и комментарий.
Вопрос: еще раз хотел вернуться, потому что не совсем для себя уяснил. Как вам видится (изначально виделась) работа клиентского кода с PlazaTrader в применении к плазовским стримам (потоками репликации). При запуске PlazaTrader из клиентского кода, PlazaTrader подключается
Комментарий: наверное, перечисление PlazaTableTypes будет лишним. Как я понимаю, оно сделано для проверки совместимости PlazaTable и PlazaColumn (см. внизу)
Но тогда подразумевается, что в PlazaTable можно передать колонки из разных наследников PlazaColumns, но с одинаковым PlazaTableTypes. А это не пройдет. Еще раз повторюсь: "синтетические" схемы из колонок разных плазовских схем (PlazaColumns) создавать нельзя. Корректным при наполненни PlazaTable набором PlazaColumn'ов будет проверять каждую PlazaColumn на одинаковость с PlazaTable по ReplicationStream, ReplicationScheme и Table(Name).
Что вы на этот счет думаете?
И то и другое. При старте настройки PlazaTable берутся из уже созданных ini файлов. Если их нет, то создается минимально допустимый набор метаданных (как это было сделано с Quik таблицами) и по свеже созданным таблицам создаются соответствующие ini файлы. Если клиентский код модифицирует PlazaTable, его действия так же применяются и к ini файлам.
Но мне не понятно эта иерархия. Стрим - репликация - таблица. Это реально нужная вещь, без которой Плаза не взлетит? Пока выглядит как избыточность.
Я думаю, неправильно было изначально делать разные PlazaColumns с одинаковыми PlazaTableTypes. Я же не знал, что для одной сущности в Плазе триллион таблиц соответствует. Потому и написал изначально, Position Portfolio и т.д. Так что да, или его переделывать, или его выкидывать.
Это не мои изобретения. Выдача данных клиентов Плазой строится следующим образом: есть несколько потоков репликации (FORTS_OPTINFO_REPL и т.д.). У каждого потока есть dbscheme. Вроде у каждого потока она одна, но пока не успел проверить точно. Зачем она нужна, если она одна, - ума не приложу. И наконец в каждом потоке есть от одной до несколько таблиц. Это их мы описывали наследниками PlazaColumns.
Чтобы подписаться на потоки и получать данные, я могу просто указать имя потока (второй конструктор PlazaStream). В этом случае будут приходить ВСЕ данные потока, т.е. если в нем несколько таблиц, например в FORTS_FUTINFO_REPL их 17 штук, их данные будут приходить через событие CP2DataStreamClass.StreamDataInserted вперемешку. Второй вариант - это, когда я отправляю на сервер содержимое ini-файла таблицы с обязательным указанием потока репликации, dbscheme, именем таблицы и списка нужных колонок запрашиваемой таблицы. В этом случае, понятно, приходят только запрошенные колонки запрошенной таблицы.
Из-за того, что процесс подписки на потоки построен именно таким образом, я считаю необходимым добавить в PlazaColumns
public abstract ReplicationStream ReplicationStream { get; } public virtual ReplicationScheme ReplicationScheme { get { return ReplicationScheme.CustReplScheme; } } public abstract string Table { get; }
У каждой таблицы потока репликации, т.е. наследника PlazaColumns, своя уникальная неизменная комбинация ReplicationStream + ReplicationScheme + Table. Она мне нужна для создания ini-файла.
Букв много. Надеюсь, что не запутал окончательно.
Стало чуть понятнее. А где теперь делать проверку, что в таблицу попала правильная колонка?
Предлагаю у PlazaColumn сделать readonly поле Owner типа PlazaColumns, инициализировать его в конструкторе PlazaColumn. В конструкторе PlazaTable перебирать IEnumerable<PlazaColumn> columns и сравнивать у каждого элемента Owner.ReplicationStream, Owner.ReplicationScheme и Owner.Table c replicationStream, replicationScheme, переданными в конструктор PlazaTable.
Как вариант, можно убрать из параметров конструктора PlazaTable параметры ReplicationStream replicationStream, ReplicationScheme replicationScheme, string name вообще и считать, что правильные параметры ReplicationStream, ReplicationScheme, name указаны в первом элементе IEnumerable<PlazaColumn> columns. Соответственно, проверку на правильность остальных элементов IEnumerable<PlazaColumn> columns проводить с значениями полей первого элемента.
Не знаю, какой вариант правильнее?
Михаил,
Хочу предложить серьезные изменения в структуре метаданных. Вместе с обоснованием хочу для наглядности выложить пример на WPF. Как это лучше сделать?
Еще, если я залью на сервер изменения, я так понимаю, их же можно будет потом назад откатить?
Написать сюда или картинку вставить.
Можно, но муторно как и любой откат.
Что я предлагаю:
А, если нужно подписаться только на одну таблицу, например orders_log, это можно сделать так``` _plazaStreamManager.AddStream("FortsOptTradeRepl_OrdersLog", PlazaReplicationStream.FortsOptTradeRepl.OrdersLog);
где columns1 это``` var columns1 = new PlazaColumn[] { PlazaReplicationStream.FortsOptTradeRepl.OrdersLog.ReplId, PlazaReplicationStream.FortsOptTradeRepl.OrdersLog.ReplRev, PlazaReplicationStream.FortsOptTradeRepl.OrdersLog.ReplAct, PlazaReplicationStream.FortsOptTradeRepl.OrdersLog.Price, PlazaReplicationStream.FortsOptTradeRepl.OrdersLog.Hedge };
Не могу сейчас развернуто вникнуть в суть проблемы.
Я думаю это неправильно. Иерархия Плазы как раз сама по себе избыточная (я так понимаю тогда задача стояла сделать что то по быстрому, а не что-то стоящее). Идти за их иерархией - просто повторять их ошибки.
PlazaTable - это то что конфигурируется пользователем. PlazaColumns - базовый класс, содержащийся основные поля. Даже не представляю, как одно может заменить другое... Плюс дальше по описанию вижу, что пользователю предлагается вынести управление потоками. Я однозначно понял за последнее время - этого делать не нужно. Лучше придерживать принципа инкапсуляции. Разрушить его можно в любое время (что опять же не очень хорошо).
Скажу так, все эти PlazaColumnListBuilder PlazaTableConfiguration говорит о том, что уже начался овер дизайн.😀 Надо как-то проще. Потому что сейчас уже не совсем понятно. Что будет потом? А что будет с теми пользователями, которые захотят переползти с голой Плазы? Одно сложное на другое сложно не меняют.
Похоже я нагородил кучу лишнего. Короче все это нужно отринуть.
МИХАИЛ: вопрос, который меня занимает сейчас больше всего: какой класс будет содержать все себе данные, которые будут приходить в потоках Плазы? Если PlazaStream мы не будем показывать клиентскому коду, тогда, может быть, это будет PlazaTable? А если не он, то что это будет за класс, и как он будет связан с PlazaTable?
По задачам, связанными с подпиской на потоки репликации Плазы я вижу, что нужно сделать следующее:
Я сейчас занимаюсь первым пунктом, а остальные пункты можно разобрать на задачи. Самым сложным и интересным вижу пункт 3.
Я думал что это будет или object[] или object[][]... Это сильно критично через что данные будут передаваться?
Ок, тогда по первому задавать вопросы не буду.
Да, причем, на мой взгляд, клиентскому коду лучше не давать доступа к PlazaTableSerializer. Пускай он это лучше делает через методы Load/Save класса PlazaTable. Формат ini-файлов это внутренность Плазы, и ее лучше, хотя бы на первых порах, инкапсулировать от клиентского кода.
Создать интерфейс IPlazaStreamFilter, у которого будет метод bool Validate(object value) и свойство string ColumnName. В конструктор PlazaTable передавать IEnumerable<IPlazaStreamFilter>, который, в свою очередь будет эту энумерацию передавать в конструктор PlazaStream. Внутри себя PlazaStream в методе void OnStreamDataInserted(CP2DataStream stream, string tableName, CP2Record record) будет перебирать эту энумерацию, вызывать для каждого элемента метод Validate(object Value) и передавать данные, приходящие в потоке репликации, дальше (в клиентский код) только, если все вызовы Validate(object Value) возвращают true. Но это только верхушка айсберга, потому что, оперируя понятиями SQL, мы только реализуем AND связки, например, price>100 AND code_vcb=xyz. А нужно еще предосмотреть, как минимум связку OR, например, price>100 OR code_vcb=xyz. Дальше я пока над этим не думал.
Взял > 4. Составные инструменты. из > Третьестепенная группа: