> > > > * In the Network example, the includedPaths only contains the id. Looking > > at my own work, I often find that IndexedEmbedded references just stores > > the id and I believe we should think about optimizing this use case. In > > that case an optimized read from the database could be executed that just > > reads that value in stead of initializing the entire entity. > > I forgot what we said around includePaths and class level bridges but > that looks like a good idea. We might be able to look at the paths and > check if any of them contains an association. If not, we could use a > projection to query the meaningful data. That's not at all how Hibernate > Search works today so I imagine that could be a significant work but > this does not look impossible. > > Can you open a JIRA issue for this. >
HSEARCH-1234 The Jira number seems appropriate for this one. > > > > > * The documentation could contain some suggestions for dealing with the > > issue of cascading initialization and how to deal with this in a smart > way. > > Sure, let's identify what we consider smart and update the doc. > Can you create a JIRA issue for that? > HSEARCH-1235 <https://hibernate.onjira.com/browse/HSEARCH-1235> > > > * In the tests I have done, saving a LinkedInPostGroup where the > > indexedEmbedded attributes (id,hidden) are *not* dirty, all the posts are > > reinitialized anyway. The reason for this is that with a Set<Tag> the set > > elements are deleted and reinserted on each save even when they haven't > > changed. > > Hum, I believe it's true for the bag semantic but I'm surprised it's > true for Set. Besides, from what you are saying, you don't add nor > remove elements from the Set, you just change some non id value. > I'll investigate some more to make sure I'm not drawing the wrong conclusion > > > > > * When a document is recreated because one attribute is changed leading > to > > all sorts of cascading database reads I often wonder: why? The reason is > > that the Index segments cannot e recreated for the indexed attributes. So > > we need to read them again. But what if those attributes are actually > > Stored in the original document and not dirty? Why not just read these > > values straight from the document with a single read in stead of > executing > > a slew of database reads? > > That might be true in some situations but FieldBridges are not > guaranteed to be non destructive in their stored data. So we cannot > generalize that necessarily. > We could explore this idea in a prototype. Again can you open a JIRA > issue? > HSEARCH-1236 <https://hibernate.onjira.com/browse/HSEARCH-1236> Cheers, Marc _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
