A singlevalued result from solr should(?) be mappeable to a collection property.

[GoogleCodeExporter]

There is a mismatch between the behaviour of solr and that of solrnet. 

If you have a solrschema with a multivalued field , but the  property in the 
.net class not enumerable, then solr will still index the field happily, and 
will return a array when searching, which breaks in solrnet.

If you have a solrschema with a singlevalued field, but a collection property 
in the .net class, then indexing still works, and searching still fails.

I would expect solrnet to be able to (at least) parse a single valued result 
into a collection property. I'm not so sure about parsing a multivalued result 
into a singlevalued property.

If you're interested I'll have a try at implementing the feature.

Original issue reported on code.google.com by rjvdb...@gmail.com on 2 Aug 2012 at 9:17

[GoogleCodeExporter]

> If you have a solrschema with a multivalued field , but the  property in the 
.net class not enumerable, then solr will still index the field happily, and 
will return a array when searching, which breaks in solrnet.

Use the mapping validation feature ( 
http://code.google.com/p/solrnet/wiki/MappingValidation ) to validate this kind 
of mismatch.

> If you have a solrschema with a singlevalued field, but a collection property 
in the .net class, then indexing still works, and searching still fails.
> I would expect solrnet to be able to (at least) parse a single valued result 
into a collection property. I'm not so sure about parsing a multivalued result 
into a singlevalued property.

This is also a mismatch and as you say it will end up throwing an error, so I'm 
strongly against allowing it. The mapping validator should report this kind of 
mismatches.

If you have a concrete use case I'll gladly discuss it, but a priori this looks 
like a bad idea.

Original comment by mauricio...@gmail.com on 2 Aug 2012 at 2:06

[GoogleCodeExporter]

Please reply, otherwise I'll have to close the issue.

Original comment by mauricio...@gmail.com on 16 Aug 2012 at 12:06

[GoogleCodeExporter]

My point was mainly that solrnet is more strict than solr itself. My usecase 
was that our solr-schema is still in flux, where fields that are singlevalued 
at the moment become multivalued. At the moment I have to be very diligent to 
synchronise any solr-schema change with the code, or else solrnet throws 
exceptions. IMO solrnet should be as lenient as solr itself, but I must say 
that my opinion is not very strong (I understand your stance perfectly).

I know about the validation-feature (I reported that the multivalued validator 
was not included by default;-), and am using it at the moment.

Please close the issue, I'll reopen one if I can come up with a strong and 
compelling usecase (but please don't hold your breath).

PS Sorry for not replying sooner, its holiday season here in the Netherlands.

Original comment by rjvdb...@gmail.com on 26 Aug 2012 at 8:35

[GoogleCodeExporter]

It may work for *some* documents in the index, but in the general case, if the 
field is multivalued and the corresponding property is not a collection, it 
will fail.
It's similar to an hypothetical ORM that silently maps an int table field to a 
string property in code. It's badly typed (it could be seen as a hidden cast) 
and will fail eventually, only there is no way to statically enforce this in C# 
(but it could be enforced in F# with a type provider).

Original comment by mauricio...@gmail.com on 27 Aug 2012 at 2:04

• Changed state: WontFix