PythonData OHLCV Security properties update logic

[D1mi3]

Added logic to allow PythonData with OHLCV attributes to update Security properties.

Description

Added code in SecurityCache.cs after Tick and IBars updates. This block allows any valid OHLCV attribute contained on PythonData _storage to set _lastOHLCUpdate.

Related Issue

Close #7793

Motivation and Context

Inaccurate backtesting results for OHLCV PythonData used as price data. (e.g. Unrealistic fill prices for limit orders as high or low properties aren't taken into account).

Requires Documentation Change

Minor documentation changes explaining the required attribute format to correctly define OHLCV PythonData bars.

How Has This Been Tested?

Backtesting results & unit tests.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• Refactor (non-breaking change which improves implementation)
• Performance (non-breaking change which improves performance. Please add associated performance test and results)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Non-functional change (xml comments/documentation/etc)

Checklist:

• My code follows the code style of this project.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>

[jaredbroad]

Hi @D1mi3 - interesting PR thank you.

Can you please shuffle the the end of the method so it doesn't impact speed, and also confirm the data is added to the cache (and thus available for fill models) with a test.

It may be easier to convert the object to an IBar instance and store that in cache vs keeping it in PythonData format.

[D1mi3]

Hi @D1mi3 - interesting PR thank you.

Can you please shuffle the the end of the method so it doesn't impact speed, and also confirm the data is added to the cache (and thus available for fill models) with a test.

It may be easier to convert the object to an IBar instance and store that in cache vs keeping it in PythonData format.

Hi @jaredbroad, thanks for the feedback. I'll soon update the PR with the shuffling suggested. With respect to the tests you mentioned; they're already implemented, please refer to them at SecurityCacheTests.cs#L365.

Finally, I agree with the simplicity of just converting PythonData to IBar, since that was my first instinct. The problem of that approach is that PythonData doesn't implement the IBar interface at all, thus it's not possible to cast. I thought about making PythonData implement IBar but ended up not doing that since it could have unintended side effects.

[D1mi3]

Hi @D1mi3 - interesting PR thank you.

Can you please shuffle the the end of the method so it doesn't impact speed, and also confirm the data is added to the cache (and thus available for fill models) with a test.

It may be easier to convert the object to an IBar instance and store that in cache vs keeping it in PythonData format.

All done.