Given this document class:
public class Product
{
public string Id { get; set; }
public string Name { get; set; }
public SpecialType? DefaultOffer { get; set; }
public Dictionary<SpecialType, string> Specials { get; set; }
}
public enum SpecialType
{
Something1,
Something2
}
And this view model that I wish to project from the above document:
public class ProductSummary
{
public string Id { get; set; }
public string Name { get; set; }
public string SpecialOffer { get; set; }
}
I have created the following index:
public class ProductSummaries : AbstractIndexCreationTask<Product>
{
public ProductSummaries()
{
Map = products => from p in products
select new { p.Id, p.Name, p.DefaultOffer, p.Specials };
TransformResults = (db, products) =>
from p in products
select new
{
Id = p.Id,
Name = p.Name,
SpecialOffer = p.Specials[p.DefaultOffer.Value]
};
}
}
In simple terms, I want the view model to use whichever of the strings in the Specials dictionary is indicated by the current value of DefaultOffer.
The following unit test fails:
[TestMethod]
public void CanIndexIntoDictionary()
{
using (var documentStore = this.GetDocumentStore())
{
documentStore.ExecuteIndex(new ProductSummaries());
// Store some documents
using (var session = documentStore.OpenSession())
{
session.Store(new Product
{
Id = "products/2",
Name = "B",
Specials = new Dictionary<SpecialType, string>
{
{ SpecialType.Something1, "B1" },
{ SpecialType.Something2, "B2" }
},
DefaultOffer = SpecialType.Something2
});
session.SaveChanges();
}
// Make sure it got persisted correctly
using (var session = documentStore.OpenSession())
{
var b = session.Load<Product>("products/2");
Assert.AreEqual("B2", b.Specials[b.DefaultOffer.Value]); // PASSES
}
// Now query and transform
using (var session = documentStore.OpenSession())
{
var result = session.Query<Product, ProductSummaries>()
.Customize(x => x.WaitForNonStaleResults())
.AsProjection<ProductSummary>()
.ToList();
Assert.AreEqual(1, result.Count);
Assert.AreEqual("B2", result.First().SpecialOffer); // FAILS - actual is NULL
}
}
}
What do I need to do to make this test pass?
* UPDATE *
By using Matt’s suggestion (in the comments below) of having an Enum value that represents NONE we can modify his answer and get rid of the nullable enum. The whole model and index looks a lot cleaner.
public enum SpecialType
{
None = 0,
Something1,
Something2
}
public class Product
{
public string Id { get; set; }
public string Name { get; set; }
public SpecialType DefaultOffer { get; set; }
public Dictionary<SpecialType, string> Specials { get; set; }
}
public class ProductSummaries : AbstractIndexCreationTask<Product,ProductSummary>
{
public ProductSummaries()
{
Map = products => from p in products
select new { p.Name, SpecialOffer = p.Specials[p.DefaultOffer] };
Store(x => x.SpecialOffer, FieldStorage.Yes);
}
}
Interestingly, this index eliminates the need for null checking and the like because RavenDB simply sets SpecialOffer to null when p.DefaultOffer is not a key contained in the Specials dictionary. (This is only true when p.Name is included in the Map.)
You don’t need a
TransformResultssection in the index. In fact, you’re mapping quite a bit that you don’t need.Idis always mapped implicitly. It becomes__document_idin the index and raven hooks it up appropriately.Nameonly needs to be mapped if you are going to filter or sort by it, which you’re not doing in the test. You can put it back if you need it for the real world.Name, you only need to mapDefaultOfferandSpecialsif you are going to use them for other purposes. For the sake of demonstration and passing your unit test, I’ve removed them.The only trickery required here is due to the nullable enum. Because of that, Raven has a hard time translating your query from c#. You can work around it with some creative null checks and use of the
AsDocumentmethod:Also note that the reason you were getting null on the special offer field before was because you were trying to project it from the index but it wasn’t a stored field. Turning field storage on for that field will solve that part of the problem.
You don’t need to store any of the other fields, because they already exist on the document – which is also a source of data for projection.
BTW – thanks for the unit test. It makes it much easier to debug and answer quickly. 🙂