I've created a common interface, ISearchHit. It has a few custom filtering options as well as a few fields related to actually displaying the search hit. Some page types implement this interface, and also some ordinary C# objects that are indexed manually.
The problem is with Search().ApplyFilters().GetResult(). GetResult will throw exceptions when it tries to deserialize the hits that are also IContentData. This forum says you should use .GetContentResult to get around this problem. But ISearchHit isn't necessarily IContentData and isn't even compiled as such.
I've also attempted to use UnifiedSearch rather than the normal search, but the whole ISearchContent deal really isn't what I need. I already have a common interface I want to work with. Plus, using unified search gives other problems, such as OriginalObjectGetter begin for my manually indexed objects.
What is the preferred way of doing this kind of search?
I use EPiServer 9 and EPiServer Find 12.2.4.
Use your interface, ISearchHit, but also use projections when retrieving the results: http://world.episerver.com/documentation/Items/Developers-Guide/EPiServer-Find/12/DotNET-Client-API/Searching/Projections/
You'll probably want to create a new class (SearchHit perhaps?) for this.
Thanks. I'll give it a shot. Will mark as answer as soon as I've tried it out and not have any follow up questions.
I've tinkered a bit with projections but I'm not sure it will solve my problem. I still get that property not found exception whenever I try to reference stuff in the projection that requires loading of the actual EPiServer content.
I little more background to how this is intended to work. I mentioned the ISearchHit interface. That's basically just two interfaces combined. First IIndexable, that is supposed to handle filtering of the objects in a common manner, and then there is IContentListItem that's the minimum required fields for an item to be displayed as a list item.
Now what complicates things...
The views for the list items may be overridden, IContentListItem is just the minimum. The data in the list item may be presented rather specific to the actual item. If the list item is a FooPage and a view named FooPageListItem.cshtml exists, it will use that for rendering. FooPageListItem.cshtml has a model of type FooPage, not just any IContentListItem. This concept is used for both search results and for blocks displaying manually picked content references. A projection won't allow me to do this since the original object gets lost when projecting. Which leads to every hit being rendered as the most basic list item. Trying to get hold of anything that has to do with the original content item when creating the projection will throw that dreaded exception again.
To summarize. I want to search for indexed objects based on a common filtering interface and return them by their actual type no matter if they are IContentData or not.
The IContent objects that resides in the index are not actually stored as IContent, but stripped down serialized versions of it. That is why you'll normally would need to use GetContentResult to get the result. What GetContentResult does is to do a Get from the database and fetch the actual IContent. From the index, you'll actually just get the content refrerence and language.Perhaps you could include the contentrefrence in your ISearchHit interface(and language if you need it), and then fetch the content after you've done the search. So you would still use projections, but also include the contentreference. By using projections, you could also use Find' highlighting options, if that is something you need.
Does this make sense? :-)
More info on highlighting: http://world.episerver.com/documentation/Items/Developers-Guide/EPiServer-Find/12/DotNET-Client-API/Searching/Highlightning/More info on GetContentResult: http://world.episerver.com/documentation/Items/Developers-Guide/EPiServer-Find/12/Integration/episerver-7-5/GetContentResult-and-GetFilesResult/
Thanks Per Magne. I think I now know enough about how it works to reach a solution.