Totally agree with Ryan. Would definitely make my life much easier if JSON.NET api was available in queries, map functions and documents. Without serializing and deserializing (basically twice). The fact that it's there in queryRow for view and not in document really touched my nerve a little bit. Please expose it.
On Friday, October 24, 2014 1:52:30 AM UTC+8, Zachary Gramana wrote: > > Ryan, > > Thanks for the post. Great question. I'm going to answer in-line below. > > Is this the intended behavior, or am I missing something? I actually think >> this is kind of cool, because the Json.NET's LINQ-to-JSON API is really >> cool. I really wish you could do this: >> >> JObject docObject = doc.ToJObject(); // Or something similar >> > > Yes, it is the "intended" behavior. I use the scare-quotes because really, > I'm punted. As a library designer, I try to make as a few decisions for > you, the user, as possible. In this case, I didn't want to much about with > embedded objects because I have no way of knowing what their original type > was, and it's a bit tedious to deal with lots of nested dictionaries. At > best, if you, as the user, know that "nestedObject" is a dictionary, you > can at least do is something like props["nestedObject"]["name"], but that > still is awkward. Instead of using standard generic dictionaries, I could > create a custom class with an indexer that would allow for stuff like > props["nestedObject.name"]. While that's better, I think most people are > just going to want to work with their own domain models. Plus, it would be > a lot of work and it's not a typical C# pattern (apart from some > data-binding libraries). > > So, I opted to leave things as is, and let the developer handle those > decisions for now. I've discussed this with some other people, and we all > feel like it's sort of surprising when you come across this, but is > ultimately appreciated. We will be adding a convenience API eventually that > will handle deserializing the entire object graph for you, but I expect > that to be implemented as extension methods so it wouldn't change any > existing behaviors. It would just handle .ToObject<T> for you. That way, if > you need to do some special processing during deserialization, you can. It > may also require the user use JSON.NET support for JSON-SCHEMA, or > something similar. This has to be very well thought out, however, and so we > won't be rushing into it. We want it to be as low friction as possible. > > >> So anyway, my main question here is: If I rely on these underlying >> Json.NET objects, will they be pulled out from under me at some point in >> the future, or is this the way it will stay? >> > > Well, you have a lot of say in this. I'm leaning toward maintaining it as > a contract, but ultimately, the community gets a large say in the matter. > ;) > -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/ab82b6c5-9d32-4e5d-afc4-10d94ff071d0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
