RE: [RavenDB] REQUEST: Allow Raven.Client to use MY version ofNewtonsoft

16 views
Skip to first unread message

Kijana Woodard

unread,
Oct 31, 2014, 9:17:35 AM10/31/14
to rav...@googlegroups.com
I think this is an issue in Nancy. Well not Nancy, but the serialization settings for whatever type you're getting. If you breakpoint and look at the dynamic type, you should see the underlying type.

Instead of using dynamic, use your transformer result class, or are you saying the transformer returns an anonymous type?

If the latter, you're probably getting a RavenJObject. Json.net doesn't know what to do with it and I bet it is derived from dictionary or some kv class resulting in the serialization you're seeing.

From: Frank Radocaj
Sent: ‎10/‎30/‎2014 8:21 PM
To: rav...@googlegroups.com
Subject: Re: [RavenDB] REQUEST: Allow Raven.Client to use MY version ofNewtonsoft

Oh. I assumed you were dealing with "document classes" that were annotated with json.net attributes. 

Sorry - I didn't clarify in my original question that this was output from transformers.

In mose cases, I would expect the transformer result class to be the "view model".

Yes, so the issue is that I don't event want to create a view model class for the result transformer.  I want to return an anonymously typed object (as dynamic) straight back out from my web api:

return session.Query<Order>()
 
.TransformWith<OrderStatisticsTransformer, dynamic>()
 
.Where(x => x.CustomerId == "customers/1")
 
.ToList();

And here in lies the problem. In my web api project (which uses NancyFx instead of ASP.Net Web API, but that's beside the point), I use Newtonsoft v6.0 as my JSON serialiser. Newtonsoft 6.0 treats my Raven.Imports.Newtonsoft dynamic anonymous type (created inside the transformer) as a dictionary and outputs:

{
 
{
     
Key: "Id",
     
Value: "users/348576"
 
},
 
{
     
Key: "Name",
     
Value: "Susie"
 
}
}

Frank
 

On Friday, 31 October 2014 11:36:55 UTC+11, Kijana Woodard wrote:
"The vast majority of the time, my queries involve indexes, and subsequently, transformers. "

Oh. I assumed you were dealing with "document classes" that were annotated with json.net attributes. If you already have a transformer result class, yes, it would be annoying to copy that to "something else". In mose cases, I would expect the transformer result class to be the "view model".

Why does that not work? How is Raven's json.net interfering with mvc serializing the class. The transformer result class is a poco defined in your code. For the raven server, it's not a c# class at all.

I think something else is going on here. Can you show some code? A repro?
What does the transformer class look like [including usings]?
Are you modifying serialization for MVC? If so, what does that look like? [I generally modify the settings for datetime serialization.]

Fwiw, I've been inundated with web api projects lately, but I can't imagine why mvc would work differently in this regard.

On Thu, Oct 30, 2014 at 5:33 PM, Frank Radocaj <frank....@gmail.com> wrote:
See response to Tom Allard.

I've never tried putting the attributes of *both* Newtonsofts on my docs. I guess I could try that, but I don't see how that is going to work. They are effectively two different assemblies that know nothing of each other. Hence, my Newtonsoft 6.0 serialises this:

class User {
 
string Id { get; set; }
 
string Name { get; set; }
}

Into this crazy JSON representation:

{
 
{
     
Key: "Id",
     
Value: "users/348576"
 
},
 
{
     
Key: "Name",
     
Value: "Susie"
 
}
}

> To me, it's more work up front and less discoverable by maintenance devs than declaring a class to shape the output.

This is not the case for me. The vast majority of the time, my queries involve indexes, and subsequently, transformers. So, my dynamically anonymous-typed "shaped output" is nicely wrapped in a transformer class that explicitly describes intent. So, my solution skips the useless step of creating superfluous view model shaped classes. Let the transformer massage the data straight out into the shape I require.

Frank


On Friday, 31 October 2014 03:42:39 UTC+11, Kijana Woodard wrote:
I guess I'm unclear as to what you want to achieve and how json.net fits in.

You want to query a document, but use json.net to shape the output of the document?
You want to put json.net attributes on the document to manipulate the output?

IIRC, you can do that by fully qualifying the attributes with "your version of newtonsoft". I thought I've seen people using "raven newtonsoft" to shape what gets saved in raven _and_ use "whatever newtonsoft" to shape what mvc serializes. I think I remember two different attributes [one from each lib version] on a single property. Either fully qualify the namespace or create an alias.

Fwiw, I've tried that path and didn't like it.

To me, it's more work up front and less discoverable by maintenance devs than declaring a class to shape the output. You can then use OfType or write a transformer to coerce the document into the right shape, if hand mapping is unappealing.

On Wed, Oct 29, 2014 at 8:31 PM, Frank Radocaj <frank....@gmail.com> wrote:
Ok, I know this is controversial, but i'm forever battling Raven.Imports.Newtonsoft against my own referenced version of Newtonsoft in my projects.

What this means is that when I query Raven, I have to "unpack" the result from the query into my own object, and then move to the next task. e.g.:

What I have to do currently in an ASP.Net MVC website:

1. Create a POCO class that is the shape of my desired "view model" result from my MVC action <== Massive pain in the arse
2. Inside my MVC action: Query Raven using docSession.Query<MyPoco>(...)
3. Return result

What I WANT to be able to do:

1. Just ONCE in my own project: Configure Raven.Client (note: NOT the server) to use Newtonsoft version of my choice (e.g. 6.0)
2. Inside my MVC action: Query Raven using docSession.Query<dynamic>(...) <=== Note the use of dynamic!
3. Return result

 This is a big friction point in development, and Raven would be sweet as if it could do this.

Please don't with respond:
- What's wrong with POCOs? The point is I don't wanna create POCOs that are just for sending out of MVC actions;
- Just use Raven.Imports.Newtonsoft in your own project. WRONG. Lots of libs require MUCH newer versions of Newtonsoft, so this won't work.

Frank

--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages