Consume the sample data directly by default about fsharp.data HOT 13 CLOSED

I agree this should be added. I think generating a constructor which loads the sample data (or loads the file specified as a static parameter) would be the best approach. Then you could write:

let csv = new CsvProvider<"file.csv">()

without even defining a new type.

from fsharp.data.

If you (or someone else) wants to add this, then please also update the samples (samples/*.fsx) because they could be nicely simplified if we had this feature.

from fsharp.data.

That constructor aproach works fine for CSV, but for JSON and XML it doesn't apply. But instead we can make the parameter of the Load/Parse methods optional, so we that when we don't pass it, it reuses the sample. I'll submit a patch soon

from fsharp.data.

Nice work!

The fact that it now uses different style for CSV than for JSON/XML is a bit unfortunate. What is the reason why using the constructor approach does not work for these two?

Also, I noticed the JSON provider tries to guess whether the string is a JSON using:

if firstChar = '{' || firstChar = '[' then

In principle, I think that true is also valid JSON. It might not be a problem (often) but if we want to do something more clever than just trying to load the file, it would probably be easier to check if the string is a well-formed URL or path.

from fsharp.data.

I think we should aim to have the following interface for all the tree options:

• static Parase method to parse a string input
• static Load method to parse a file or URL
• constructor to parse or load the input according to static parameters

If the constructor takes a string, then it is not clear what is that supposed to mean (it is not too bad, because there is probably a tool tip, but I think having a clear API is better).

from fsharp.data.

While the Parse and Load methods of CSV return an instance of CsvFile, on XML/JSON the return type is an instance of a root under the domain types, so we can't just use the constructor.

We have Load and Parse methods for all, and while for CSV we have the constructor, for XML/JSON, the Load or Parse method (according to if we provided a file or inline data) can be called without parameters, so effectivly the static parameters become the default runtime parameters.

I'd also like to make the 3 providers as similar as possible, but they are very different, CSV is a matrix, JSON/XML are trees, so there's more stuff that's probably going to become different between XML/JSON and CSV, like the write api, for example

from fsharp.data.

About the guessing in the json provider, I'll fix that, I did it to avoid having a lot of exceptions being thrown while debugging, but unlike the xml is not 100% reliable so it needs to have a fallback

from fsharp.data.

Actually, the code is already right, if there's { or [, it knows for sure is not a filename, otherwise it still tries both

from fsharp.data.

Ah, I see.

Okay, let's leave it like this for now, but I would like to avoid this mismatch somehow (but it definitely needs more thinking than I thought :-)).

from fsharp.data.

Just consider this a first draft, we'll probably still change the api a couple of times until we're happy.
I think all the providers still need a lot of work until they mature, every time I try them on real data I find another thing I want to change :)

from fsharp.data.

Sure, I'm just thinking aloud here :-) Thanks for all the hard work on improving the providers as well as on the portable version, you've made some excellent progress here!

from fsharp.data.

While porting the FSharpx unit tests, I come to the conclusion that .Load() and .Parse() to get the default data is weird, trying something else

from fsharp.data.

Are you ok with the current .GetSample() solution for Xml and Json?

from fsharp.data.