[hibernate-dev] The problem of cascading database reads

[Marc Schipperheyn]

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