You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
a CDI bean reference can be used here instead by providing the bean name,
114
109
for example, if the loading binder requires access to some CDI beans and is a CDI bean itself.
115
-
====
116
110
117
111
That is all that is needed to tie things together.
118
112
The only open question is how to implement the mass loading strategy.
@@ -134,7 +128,6 @@ than just pass through the batch of received "identifiers", which are actual ent
134
128
With that in mind, the mass-loading strategy may be implemented as:
135
129
136
130
[source, java]
137
-
====
138
131
----
139
132
new MassLoadingStrategy<Guide, Guide>() {
140
133
@Override
@@ -167,7 +160,6 @@ it is slightly trickier than the pass-through entity loader.
167
160
Hence, we would want to take a closer look at it.
168
161
2. An implementation of the pass-through entity loader.
169
162
3. As explained above, we treat the search entities as identifiers and simply pass the entities we receive to the sink.
170
-
====
171
163
172
164
NOTE: If passing entities as identifiers feels like a hack, it's because it is.
173
165
Hibernate Search will, at some point, provide alternative APIs to achieve this more elegantly: link:https://hibernate.atlassian.net/browse/HSEARCH-5209[HSEARCH-5209]
@@ -178,7 +170,6 @@ We could do this by using the `MassLoadingOptions options`.
178
170
These mass loading options provide access to the context objects passed to the mass indexer by the user.
179
171
180
172
[source, java]
181
-
====
182
173
----
183
174
@Inject
184
175
SearchMapping searchMapping; // <1>
@@ -198,6 +189,8 @@ for an example of how such context can be implemented.
198
189
4. Set any other mass indexer configuration options as needed.
199
190
5. Create a mass indexer.
200
191
6. Start the indexing process.
192
+
193
+
[source, java]
201
194
----
202
195
public class GuideLoadingContext {
203
196
@@ -220,14 +213,12 @@ public class GuideLoadingContext {
220
213
2. Read the next batch of the guides from the iterator. We are using the batch size limit
221
214
that we will retrieve from the mass-loading options
222
215
and checking the iterator to see if there are any more entities to pull.
223
-
====
224
216
225
217
Now, having the way of reading the entities in batches from the stream
226
218
and knowing how to pass it to the mass indexer, implementing the identifier loader
227
219
can be as easy as:
228
220
229
221
[source, java]
230
-
====
231
222
----
232
223
@Override
233
224
public MassIdentifierLoader createIdentifierLoader(LoadingTypeGroup<Guide> includedTypes,
@@ -270,7 +261,6 @@ for the current mass indexer.
270
261
4. If the batch is empty, it means that the stream iterator has no more guides to return.
271
262
Hence, we can notify the mass indexing sink that no more items will be provided by calling `.complete()`.
272
263
5. If there are any guides in the loaded batch, we'll pass them to the sink to be processed.
273
-
====
274
264
275
265
To sum up, here is a summary of the steps to take to index an unknown number of search entities from a datasource
276
266
while reading each entity only once, and without relying on lookups by identifier:
0 commit comments