HSEARCH-3573 Use consistent naming for hits and projections #1972
Conversation
This file contains 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
yrodiere
added
the
Waiting for other pull request
|
Jenkins, retest this please |
Pull Request Test Coverage Report for Build 6
💛 - Coveralls |
yrodiere
added
Ready for review
and removed
Waiting for other pull request
fax4ever
reviewed
May 14, 2019
.../src/main/java/org/hibernate/search/engine/search/dsl/query/SearchQueryContextExtension.java
Outdated
Show resolved
Hide resolved
...csearch/src/main/java/org/hibernate/search/backend/elasticsearch/ElasticsearchExtension.java
Outdated
Show resolved
Hide resolved
.../java/org/hibernate/search/util/impl/integrationtest/common/stub/mapper/StubMapperUtils.java
Outdated
Show resolved
Hide resolved
| @@ -176,7 +176,7 @@ such as `SearchPredicateFactory` or `FieldSortBuilder`. | |||
|
|
|||
| Note that the APIs implemented by the engine include ways for the mapper to wrap the resulting search query | |||
| (`SearchQueryWrappingDefinitionResultContext#asWrappedQuery`). | |||
| Also, the SPIs implemented by backends allow mappers to inject an "object loader" (see `SearchQueryBuilderFactory.asObject`) | |||
| Also, the SPIs implemented by backends allow mappers to inject an "entity loader" (see `SearchQueryBuilderFactory.asObject`) | |||
There was a problem hiding this comment.
I think we should expose in our documentation in a very clear way what we meant for an entity.
Maybe it is just a first class object to handle indexes and
not necessarily an Hibernate ORM Entity nor an Entity Bean.
There was a problem hiding this comment.
I added a TODO to explain that where we explain the concept of "mapping".
engine/src/main/java/org/hibernate/search/engine/search/loading/spi/LoadingResult.java
Show resolved
Hide resolved
...pojo/src/main/java/org/hibernate/search/mapper/pojo/mapping/impl/PojoIndexedTypeManager.java
Show resolved
Hide resolved
…ntity queries and projections
…rmer This was replaced with projections some time ago, so we don't need the extra complexity that it used to bring.
… generic projection types
…in the documentation
|
Thanks! I addressed your comments. Waiting for CI... |
|
@yrodiere +1 to merge. May I do it after the CI finishes? |
|
@fax4ever Sorry I didn't see you message. Well, I'm here now, I'll merge. Thanks! |
|
@yrodiere it's the same. Thank you |
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.
HSEARCH-3573: Use consistent naming for hits and projections
Based on #1971 , which should be merged first.=> DoneThis is strictly about method and generic type parameter names. There's a lot of changes, but very few of them are significant. I just need to know if the idea seems sound: maybe you can determine that from the commit messages? I don't want to force you to go through the entire diff...
The only significant change is the renaming of the
object()projection toentity(), to be consistent with the wording ofasEntity()when creating a query.