Repository navigation
Fix DocumentCatalog search on interface-typed index filters - #278
Merged
Merged
Conversation
PageAsync filtered with query.With<INameAwareIndex>(...), With<IDisplayTextAwareIndex>(...) and With<ISourceAwareIndex>(...). YesSql maps the type argument to an index table, and a marker interface has none, so any search or source filter threw "no such table: IDisplayTextAwareIndex_Document". Build the filter and the sort expressions for the concrete TIndex, and add SQLite integration tests that page a catalog with a search term.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
DocumentCatalog<T, TIndex>.PageAsyncthrew on every search. With aQueryContextthat setsNameorSource, it filtered with:YesSql maps the type argument of
With<TIndex>to an index table. A marker interface has no table, so SQL went to a table that does not exist:The same happens for
INameAwareIndex_DocumentandISourceAwareIndex_Document. A downstream host found it: every server-side admin list search returned HTTP 500 (Orchard Core AdminList withOptions.Search).Fix
PageAsyncnow builds the filter and the sort expressions for the concreteTIndex. It uses the interface'sPropertyInfoon aTIndexparameter, which is the same expression the compiler emits for a genericTIndexconstrained to the interface (asNamedDocumentCatalog.FindByNameAsyncdoes). So YesSql binds the column to the concrete index table thatSession.Query<T, TIndex>()already joined. The behavior is otherwise unchanged:NamechecksINameAwareIndexfirst, thenIDisplayTextAwareIndex;Sortedorders by the same column;Sourcefilters by equality.Tests
New
DocumentCatalogPageTestsrunPageAsyncagainst a real in-memory SQLite YesSql store with test index types:INameAwareIndex, sorted and not sortedIDisplayTextAwareIndex, sorted and not sortedAll 6 fail on
mainwith theno such tableerror and pass with the fix. The YesSql and catalog tests (158) pass, and the test project builds with-warnaserror -p:TreatWarningsAsErrors=true -p:RunAnalyzers=true.Docs
changelog/2.0.0.md: a "Fixed" entry.core/data-storage.md: the Pagination section now tells howQueryContextfilters a page.