Метаданные. Как сейчас они заполняются?

см. конструктор PlazaSystemTableRegistry

Понял. Но это же не совсем то, о чем в начале планировали. Сейчас нет ни парсинга схем, ни сохранения, ни минимального набора колонок (как я понял, добавляются вообще все колонки). Это в планах стоит или решил идти по другому? Это первое.

И второе, а почему ты решил отделить основные таблица от других в PlazaSystemTableRegistry? Из его описания:



Выделенное как раз неправильно. А если пользователь захочет дополнительные колонки для инструментов или заявок? Они должны идти в Security.ExtensionInfo (для заявок Order.ExtensionInfo).

PlazaTableRegistry - в нем все таблицы Плазы для клиента. Создаются пустые, без колоннок. На клиенте лежит обязанность наполнить их перед тем, как передать в StartListeners. Можно, кстати, по умолчанию добавлять первыми во все таблицы поля replID, replRev, replAct, потому что они нужны всегда. Без них Плаза будет сыпать ошибки.

PlazaSystemTableRegistry - нужен нам, чтобы мапить объекты. Этот класс, кстати, скрыт от клиентского кода.



Я как-то спрашивал (может не совсем дотошно), нужно ли нам сохранять state схем, меняющийся от одного запуска программы к другому. То есть мы пока не обрабатываем такой сценарий: пользователь запустил PlazaTrader, добавил в коде в таблицу 1 колонки 1, 2, 3, поработал, вышел. Пользователь снова запустил PlazaTrader, рассчитывая, что мы уже за него заполнили таблицу 1 колонками 1, 2, 3, добавил в таблицу 1 колонку 4, убрал колонку 2, поработал вышел, уверенный, что, когда он в следующий раз заполнит PlazaTrader, мы за него заполним таблицу 1 колонками 1, 3, 4. Или так должно быть[confused]
Сейчас, как я вижу, сценарий такой: пользователь запустил PlazaTrader, добавил в коде в таблицу 1 колонки 1, 2, 3, поработал, вышел. Снова запустил, заполнил своим кодом те же метаданные, поработал, вышел, и так до бесконечности. Если это так, мой алгоритм действий проще: на основе заполненных PlazaTables внутри PlazaTableRegistry создаются временные файлы-схемы, которые передаются роутеру Плазе.


Не совсем понял, но попытаюсь ответить. Что это за дополнительные колонки и откуда они будут браться? Если, например, рассматривать метод OnNewDataFromOptionSessionContents (мапит объекты Security опиционов), в нем есть все колонки, которые есть в потоке\таблице FORTS_OPTINFO_REPL\opt_sess_contents. Если клиент хочет добавить что-то дополнительное, ему придется это делать вручную, потому что Плаза не примет схему с чужими колонками.

Согласен, это правильно. Еще лучше сделать проверку на удаление в PlazaColumnList чтобы выдывать сообщение об ошибке при удалении колонки, которая PlazaColumn.IsMandatory = true. Особое внимание, IsMandatory это не только replID, replRev, replAct. Для, допустим, заявок это еще номер, время, объем и т.д. Вообщем то, без чего не может произойти минимальный маппинг.



Понял, тут ты прав абсолютно. Я прогнал.



Выделенное неправильно. В целях оптимизации трафика нужно создавать только минимальный набор параметров у этих таблиц. Можно решить какой. Для этого и я ввел свойство PlazaColumn.IsMandatory. Это те колонки, без которых нельзя обработать нормально поступившие данные. Сам понимаешь, если по инструменту придут только replID, replRev, replAct, понять что есть что мы не сможем.

А вот когда юзеру требуется что-то дополнительное, он сам себе отдает отчет в увеличении трафика и добавляет колонку как ты описал выше.

Ты уже сам это сделал[smile]



Сделал рефакторинг двух классов PlazaSessionContentsFutureColumns и PlazaSessionContentsOptionColumns (и их родителя, конечно же, PlazaSessionContentsDerivativeColumns) по принципу, что не мапится, то необязательное. Если правильно, доделаю отстальные системные таблицы. Что касается остальных таблиц, это уже нужно смотреть тем, кто "работает по профилю".

Прописал автоматическое добавление служебных колоннок репликации (replID, replRev и replAct) в статическом конструкторе PlazaTableRegistry. Более лучшего места не нашел.

Поправил код. AddSystemColumns сам по себе не имеет смысла, потому что это и есть подмножество IsMandatory. Но добавлять нужно абсолютно все колонки IsMandatory = true для всех таблиц.

И так по мелочи, в виде вынесения кода AddMandatoryColumns в хелпер класс.

В конструкторе PlazaSystemTableRegistry сделал тоже самое, что и в PlazaTableRegistry. Код вроде как меньше получается. Можно вернуть, если против.

После изменений PlazaSystemTableRegistry кажется опять лишним классом. В чем фишка его отдельного существования от PlazaTableRegistry? Логики то он никакой не содержит.

Наконец я узрел истину[smile] Только что удалил PlazaSystemTableRegistry, потому что он действительно лишний. Раньше я почему-то думал, что пользователь может удалить нужные нам колонки в какой-нибудь таблице, и мы не сможем мапить объекты. Теперь понял, что это у него не получится.

Сейчас собираюсь поправить поля IsMandatory в таблицах, из которых мы мапим объекты. А что дальше? Заявки?

Да, было бы неплохо.