2.2k
views3
comments

Is there a way to reuse the type serializer to Json you've built. It would be for other purpose like serializing to a file.

I do not know of working serializer for discriminated unions as of yet.

Thanks,

David

Hi David, we don't officially support it so I wouldn't recommend using it.

I have had written a number of generic serializers in F# for F# use. They all have a very similar structure, but each time you have to decide:

1. which data format are you using?

2. which types to suport - usually this includes the closure of scalars with unions, tuples, arrays and records, but it can vary - do you need support for serializing objects? interface/subtype values? if so, would you support closures? are collections to be treated specially?

3. are there cycles in the object graph?

4. are the serialization rules extensible, and if so, how?

5. are decoding and encoding to be treated separately (do you need to derive encoders for types when decoders aren't available)?

If I were to maintain this as a library, I would try to express it generically, so that these decisions could be done by the user. Unfortunately I haven't succeeded in making it nice - I tried a few times but it always looked ugly. So for now I usually just commit to specific choices and then write the code.

As a specific example, let's say we want to (1) serialize to binary; (2) support non-virtual F# types and rank-1 arrays, and support a few specific collections (Dictionary, Map, Set); fail on functions or interfaces; (3) ignore object cycles - unspecified behavior; (4) do not provide extensibility; (5) handle encoding and decoding together. Here is how it might look like:

[link:gist.github.com]

Anton

By Anton Tayanovskyy on 7/14/2011 8:13 AM (permalink)

Wow this is just fantastic... I think I can start with that.

But to answer your questions:

1- This is irrelevant, doesn't have to be human readable, as long as deserialization can be done at a reasonably fast rate.

2- Discriminated Unions, Tuples, F# Records and collections.

3- I don't think so, documents could be serialized as an entire graph i.e. no references between two entities.

4- Yes, I have to be able to deserialize old version of entities into new version if field matches. But I could handle reprocessing the documents manually if I have to change the structure.

5- I don't understand the question, I would assume it's together.

I want to build a back-end site in a CQRS approach where I use F# discriminated unions for the various types of commands (events). These would be my master source of data. I do not intend to maintain the state of views in a database but in memory at run time. If the site is brought down or crashes, I reprocess all events from point zero to rebuild the views. View states will be kept inside F# agents. If performance is a concern at application startup, I might serialize the view states (likely F# records) on changes and reload that instead of reprocessing all events. View states is entirely denormalized, the events being my master source of data. Note that I never query the serialized events at run time as I preserve the state of all views at all time (i.e. no querying in the system whatsoever) and I would only deserialize the events at application startup.

Thanks a lot for your help!

David

By David Grenier on 7/14/2011 4:58 PM (permalink)

iPhone 5 cases

iPhone 5 covers

iPhone 5 Accessories

iPhone 5 screen protectors

By dandanmian on 7/26/2011 7:12 AM (permalink)