Re: [hibernate-dev] The problem of cascading database reads

> * 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.

> > * 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?

> * 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.

> > * 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?