Oh. I assumed you were dealing with "document classes" that were annotated with json.net attributes.
In mose cases, I would expect the transformer result class to be the "view model".
return session.Query<Order>()
.TransformWith<OrderStatisticsTransformer, dynamic>()
.Where(x => x.CustomerId == "customers/1")
.ToList();
{
{
Key: "Id",
Value: "users/348576"
},
{
Key: "Name",
Value: "Susie"
}
}
"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 arse2. Inside my MVC action: Query Raven using docSession.Query<MyPoco>(...)3. Return resultWhat 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 resultThis 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.