Lost DataSet in custom data provider
Author: ranchsong
Creation Date: 9/4/2020 7:00 PM
profile picture

ranchsong

#1
I am developing some data provider. Suddenly, I got into some weird situation.

I can create dataset, but when I reopen WLD, the dataset is not listed in left tree.
I attached several pictures to explain what I am facing, hopefully, someone can help.

1, DummyDataSetCreated:
this image shows a dummy dataset is created and listed in the left tree.
the dataset file is created under the DataSet folder,
WealthLab.DataProviders.Dummy.dll is in exe folder as expected.

2, DummyDataSetLost:
Then I close WLD, and reopen WLD. The dummy dataset is no longer listed.
(BTW, I noticed, Yahoo Dow 30 is always expanded when such lost happens)

3, DummyStaticDataProvider:
This is the dummy data provider code
No extra references other than .Net framework and Wealthlab dlls
No serialiation and deserialization

4, VisualStudio2015DebugException
Things get even worse, that I can't debug through Visual Studio 2015/2017/2019 suddenly.
It gets into the exceptions show in the image (across multiple machines)

BTW, all is fine two days ago. So, I suspect it is because of my dev box has some change in system, but it does not seem to work on another machine. (They are all in Windows 10, VS 2015/17/19)

Please help and thanks
profile picture

ranchsong

#2
And furthermore, the WLD is a fresh installation, without uninstall or install of any extra extensions other than those default bundled.
profile picture

Eugene

#3
QUOTE:
Then I close WLD, and reopen WLD. The dummy dataset is no longer listed.

This is fine. This DSString is incomplete and cannot be used to deserialize the DataSet. That's why it will always disappear on restart. Log in to the Wiki and download sample code for example (protected, customer-only content).

QUOTE:
Things get even worse, that I can't debug through Visual Studio 2015/2017/2019 suddenly.

If you're noticing some WLD misbehavior, uninstall it, remove the installation folder under Program Files, and reinstall from scratch. Then make sure that your solution 1) targets .NET framework 4.6.2 or 4.7.1 and 2) not references any unsuitable DLLs (such as leftovers from a WLP installation).
profile picture

ranchsong

#4
QUOTE:
If you're noticing some WLD misbehavior, uninstall it, remove the installation folder under Program Files, and reinstall from scratch. Then make sure that your solution 1) targets .NET framework 4.6.2 or 4.7.1 and 2) not references any unsuitable DLLs (such as leftovers from a WLP installation).

I did. It is a fresh installation, and the dummy provider is targeting 4.6.2.

QUOTE:
This DSString is incomplete and cannot be used to deserialize the DataSet.

The dataset file looks like the following, which seems valid:
<?xml version="1.0"?>
<DataSet xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Name>Dummy(1 Min)</Name>
<Scale>Minute</Scale>
<BarInterval>1</BarInterval>
<DSString>1 Min</DSString>
<ProviderName>DummyTest</ProviderName>
</DataSet>

I have other samples that is similar but used to work, and suddenly doesn't work.
profile picture

ranchsong

#5
Here is my actual sample of DataSet file. The DSString is using Json serialization and deserialization.
It works several days ago, but now doesn't work.

<?xml version="1.0"?>
<DataSet xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Name>IB (Daily 1)</Name>
<Scale>Daily</Scale>
<BarInterval>1</BarInterval>
<DSString>{
"Symbols": [],
"BarScale": 0,
"BarInterval": 1,
"Upto": "2010-09-03T00:00:00-05:00",
"ProviderName": "IBDP"
}</DSString>
<ProviderName>IBDP</ProviderName>
</DataSet>
profile picture

Eugene

#6
QUOTE:
The dataset file looks like the following, which seems valid:

No it's not.

QUOTE:
It works several days ago, but now doesn't work.

This one may appear in the DataSets tree but the symbols are empty so it shouldn't work.
profile picture

ranchsong

#7
QUOTE:
This one may appear in the DataSets tree but the symbols are empty so it shouldn't work.


I recreate it with symbols: I can create the dataset, but still lost when reopen WLD

<?xml version="1.0"?>
<DataSet xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Name>IB (Daily, 1)</Name>
<Scale>Daily</Scale>
<BarInterval>1</BarInterval>
<DSString>{
"Symbols": [
"AAPL"
],
"BarScale": 0,
"BarInterval": 1,
"Upto": "2010-09-04T00:00:00-05:00",
"ProviderName": "IBDP"
}</DSString>
<ProviderName>IBDP</ProviderName>
</DataSet>

Is there any error log showing the loading exception?
profile picture

Eugene

#8
Look, your code screenshot above does not implement DataSet deserialization. Samples that do are referenced in post #3.
profile picture

ranchsong

#9
QUOTE:
your code screenshot above does not implement DataSet deserialization. Samples that do are referenced in post #3.


All DataSet samples (mentioned above) can be created and are shown after creation, but all of them are lost when reopen WLD.

I guess, WLD is using .Net DataSet object to read in the xml file.
I tried to read in using .Net DataSet's ReadXml(), and I can load in the dataset files, which means, they are valid xml files.

I also turned on log level to All in WLD.exe.config file, but nothing is written out to wld.txt.

Because it can be reloaded (several days ago) when reopen WLD, I really need some help to figure out why.
Anything to try? Or any insights of how the lost may happen?

QUOTE:
Things get even worse, that I can't debug through Visual Studio 2015/2017/2019 suddenly.

I figured out the problem is from the Yahoo data provider default packaged with the V6.9.23.1.
After update the Yahoo Static Data Provider to the latest (from extension prompt window), then debug is able to go through.
profile picture

Eugene

#10
I still don't seem to communicate my point to you well. It doesn't matter what "WLD is using" nor to check for "XML validity". To get your DataSets to restore on restart, please study the sample code and implement serialization and deserialization exactly like shown.

QUOTE:
I figured out the problem is from the Yahoo data provider default packaged with the V6.9.23.1.
After update the Yahoo Static Data Provider to the latest (from extension prompt window), then debug is able to go through.

Right on. V2020.02.23 fixes an obfuscation bug that caused debug failure:

* Fixed: provider caused FatalExecutionEngineError when debugging, making impossible to debug other projects in Visual Studio
profile picture

superticker

#11
QUOTE:
I can load in the dataset files, which means, they are valid xml files.

Perhaps, but the <DSString>...</DSString> still needs to have a valid list of ticker symbols. For example, <DSString>ACAD,APTX,BERY,CYBE,MTCH,RGNX,SHOP</DSString> as in the XML file ...
CODE:
Please log in to see this code.

You simply need to fix the symbol list you're assigning to the <DSString> string to. I think the rest of your XML file might be okay.
profile picture

Eugene

#12
No, this is not enough. Unlike Fidelity and IQFeed providers, his provider has custom fields (e.g. "Upto": "2010-09-04T00:00:00-05:00") which requires a custom de/serialization routine.
profile picture

ranchsong

#13
QUOTE:
No, this is not enough. Unlike Fidelity and IQFeed providers, his provider has custom fields (e.g. "Upto": "2010-09-04T00:00:00-05:00") which requires a custom de/serialization routine.


QUOTE:
<DSString>ACAD,APTX,BERY,CYBE,MTCH,RGNX,SHOP</DSString>

CODE:
Please log in to see this code.


For one of my sample dataset, it does requires custom de/serialization. But I do create the above dataset without custom de/serialization involved. No luck.

QUOTE:
please study the sample code and implement serialization and deserialization exactly like shown

I am following the sample Google Provider's CreateDateSource() as following code, which shows DSString with custom deserialization.
Mine is using json serialization, instead of soap serialization.
But I did change mine to soap serialization exactly like google's, still no luck.

CODE:
Please log in to see this code.

Can you please point out a particular provider sample code for me to follow (other than google provider)?
Or can you share a different version of WLD for me to try? (Say, beta version? I kind of guess something to do with dll conflict)

Thanks
profile picture

ranchsong

#14
One extra observation forgot to mention.

Say, I created a dataset of Interactive Broker 5 Minute. And close WLD, then reopen WLD, the dataset will be lost.
But when I try to recreate a dataset of same name, I will be prompted that the dataset already exists.

This means: the dataset may have been loaded into WLD, but for whatever reason, it doesn't show up in the tree.

Then, what could the reason leading to the tree not showing a dataset? Any insights?
profile picture

ranchsong

#15
Finally, I find out the root cause.
There is no problem with serialization of any dataset samples mentioned above.

I attached two pictures:
1, DataSetDifference: left is the working sample, right is the none-working sample
IBStaticDataProvider is my class name who inherits StaticDataProvider
IBDP is a nice constant string I defined in IBDataProviderInfo.Provider

2, DataSetDifferenceCode: after comment out the line 178, it works.

So, the root cause is:
I happen to set DataSource.ProviderName to something other than the class name, since the property is settable.

Thanks for all your help and hopefully this could be helpful.
profile picture

Eugene

#16
QUOTE:
This means: the dataset may have been loaded into WLD, but for whatever reason, it doesn't show up in the tree.

The reason is that your provider has created the DataSet, serialized it but apparently deserialization is broken as WL fails to recognize the otherwise valid XML and show it in the DataSets tree. For insights on why it happens:

1. Run your project under debugger setting a breakpoint all the way from ctor().
2. Pay attention to what happens in its "GoogleSettings.DeserializeFromString" analogue (another breakpoint).

UPDATE:
Just saw your post #15 after having typed in my reply:
QUOTE:
I happen to set DataSource.ProviderName to something other than the class name, since the property is settable.

Glad to see you've figured out the source of error! Which is akin to bad deserialization where an entity (wrong class name) could not be mapped to itself.
This website uses cookies to improve your experience. We'll assume you're ok with that, but you can opt-out if you wish (Read more).