DataContract attributes clashing with index definitions?

[BrettN]

Hi,

my data model makes use of DataContract attributes. I can see these being used by RavenDB (via Json.net) when serializing and storing documents. The names of the properties, as stored, are the names I define within the DataContract attribute.

However, when I generate my indexes, via AbstractIndexCreationTask on App_Start, the index that is created in Raven does not use the DataContract defined names. Therefore, my indexes return no data as they are trying to index properties that don't belong to any stored documents.

1. Does that description make sense?
2. Is there a solution to this?
   
3. Is it possible to disable Json.net using the DataContract attribute via Raven's conventions?

Thanks,

[Tobi]

On 03.05.2012 03:24, BrettN wrote:

> 1. Does that description make sense?

Sure. Besides its own attributes Json.Net uses DataContract/DataMember
(opt-in).

> 2. Is there a solution to this?

You can define your indexes "manually" as a string:

Map = "from doc in docs select new { doc.Name }"

...this way you can use any property name, even those that you have
"renamed" with DataContract/DataMember.

> 3. Is it possible to disable Json.net using the DataContract attribute
> via Raven's conventions?

I don't think so. Ran into the same issue when I had some WCF code
operating on the same POCO's as RavenDB. I've extracted some DTO's to
workaround this but replaced WCF altogether later on, so this wasn't an
issue for me anymore.

Tobias

[BrettN]

Thanks Tobias,

where are you referencing Map as a string? I can't find any references to that and the Map property within AbstractIndexCreationTask is of type Expression.

Brett

[Mauro Servienti]

If you inherit from the “generic” AbstractIndexCreationTask<T> the Map and Reduce properties are strongly typed expressions, if you inherit from the non-generic base class AbstractIndexCreationTask they are strings, in the end server side they are always strings.

.m

[BrettN]

Thanks all,

this got me over the finishing line.

Brett