Баго-фича при сохранении данных Trade

В примере нет самого важного параметра - номера сделки. Что-то я недооценил этот параметр. Его нет ...

2012-11-15T22:21:47Z

Mikhail Sukhov

В примере нет самого важного параметра - номера сделки.

Что-то я недооценил этот параметр. Его нет потому, что его нет[bored] Т.е. он всегда ноль.
Искусственные сделки я создаю вот таким кодом, который находится в подкрученном HydraQuikTrader.cs:
(QuikStockIndexes - моя собственная структура, используемая в кастом таблице, откуда я буру данные)

Code


                List<Trade> toTrades = new List<Trade>();
                foreach (QuikStockIndexes si in _idxData)
                {
                    var mySecurLst = _secur.Where(s => (s.Id == (si.SecurID + "@" + si.ClassID)));
                    if (mySecurLst.Any())
                    {
                        var mySecur = mySecurLst.First();
                        var myTrade = new Trade
                        {
                            Security = mySecur,
                            Price = si.Price, //decimal.Round(si.Price, 4),
                            Volume = 1,
                            Time = si.UpdateTime,
                            Latency = si.Latency,
                            OrderDirection = OrderDirections.Buy
                        };
                        toTrades.Add(myTrade);
                    }
                }

                smTestLog( toTrades);

                if (toTrades.Any())
                    RaiseNewTrades(toTrades);

Для правильного сохранения нужно обязательно определять еще и Id?
Тогда не подскажете ли как правильно его определять? Можно ли использовать простой счетчик или нужно что-то более сложное?

Хотелось бы понять более четко, действительно ли делается какая-либо отбраковка данных при сохранен...

2012-11-14T20:57:24Z

DrChemist

Хотелось бы понять более четко, действительно ли делается какая-либо отбраковка данных при сохранении, и по каким принципам?

В примере нет самого важного параметра - номера сделки.

Проверил на версии 4.1.6 Подтверждаю. Проблема устранена полностью . Данные читаются и восстанавлива...

2012-11-14T17:25:44Z

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

Для тех, кому это может быть нужно, обращаю внимание, что, по всей видимости, формат записи изменился. Мне не удалось прочитать данные записанные версией 4.1.6 программой, использующей библиотеку 4.1.5

Однако я обнаружил еще один эффект, с которым хотел бы разобраться.
Дело в том, что я обнаружил, что в хранилище сохраняются не все искусственные сделки, которые я создаю.
Возможно, происходит некоторая фильтрация ( возможно, правильная) или в _tradesBuffer Гидры или в самом хранилище.

Дело в том, что данные из кастом таблиц Quik, по всей видимости, приходят с дублированием:

Вот типичный пример, сделанный по моим собственным независимым логам:

Code


1. miniSP500&WIDX,20:14:01,2012-11-14 20:14:01.0(00:00:01.9850995),1365.73553345389,buy
2. miniSP500&WIDX,20:14:01,2012-11-14 20:14:01.0(00:00:01.9850995),1365.73553345389,sell
3. miniSP500&WIDX,20:14:02,2012-11-14 20:14:02.0(00:00:00.9850995),1365.73553345389,buy
4. miniSP500&WIDX,20:14:02,2012-11-14 20:14:02.0(00:00:00.9850995),1365.73553345389,sell
5. miniSP500&WIDX,20:14:02,2012-11-14 20:14:02.0(00:00:01.9444995),1365.73704038577,buy
6. miniSP500&WIDX,20:14:02,2012-11-14 20:14:02.0(00:00:01.9454995),1365.73704038577,sell
7. miniSP500&WIDX,20:14:03,2012-11-14 20:14:03.0(00:00:00.9464995),1365.73704038577,buy
8. miniSP500&WIDX,20:14:03,2012-11-14 20:14:03.0(00:00:00.9464995),1365.73704038577,sell

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

Если посмотреть, например, на строки 2 и 4, 5 и 7, то видно, что они соответствуют строго одному и тому же компьютерному времени, но задержки как-бы разные. Все параметры сделки, кроме времени в них идентичны.

Для каждой строчки была создана соответствующая искусственная сделка, которая помещалась в _tradesBuffer обычным образом.

Из хранилища были прочитаны вот эти данные:

Code


[1]	{2012-11-14 20:14:01 0 1365.73553345389 1}
[2]	{2012-11-14 20:14:01 0 1365.73553345389 1}
[3]	{2012-11-14 20:14:02 0 1365.73553345389 1}
[4]	{2012-11-14 20:14:02 0 1365.73553345389 1}
[7]	{2012-11-14 20:14:03 0 1365.73704038577 1}
[8]	{2012-11-14 20:14:03 0 1365.73704038577 1}

Т.е. сделки, соответствующие строкам 5 и 6 были отфильтрованы (отбракованы?) и не были сохранены.

Хотелось бы понять более четко, действительно ли делается какая-либо отбраковка данных при сохранении, и по каким принципам?

Проблема определена. Будет фикс на Кодеплексе. Сейчас хранилище поддерживает цены, не кратные шагу. ...

2012-11-12T12:06:53Z

Mikhail Sukhov

Проблема определена. Будет фикс на Кодеплексе. Сейчас хранилище поддерживает цены, не кратные шагу. Предполагается, что такая цена может возникнуть у внесистемных сделок (не обязательное условие).

Фикс доступен на кодеплексе. Просьба отписаться о результатах.

Проблема определена. Будет фикс на Кодеплексе. Сейчас хранилище поддерживает цены, не кратные шагу. ...

2012-11-10T21:26:37Z

Решил описать один неприятный эффект, с которым мне пришлось столкнуться и который, увы, забрал мног...

2012-11-10T15:50:10Z

Решил описать один неприятный эффект, с которым мне пришлось столкнуться и который, увы, забрал много времени.

Если Trade.Price содержит «лишние» десятичные цифры после запятой (по всей видимости, цифры большей точности, чем Security.MinStepPrice), то при сохранении таких данных в TradeStorage и последующем чтении данные очень сильно искажаются ( более чем на 100%) из-за больших накапливающихся ошибок.

У меня этот эффект возник при генерации и сохранении искусственных сделок, информацию для которых я брал из альтернативных (кастом) таблиц (мировые индексы, по которым не поступала информация в таблицу всех сделок).