[Date Prev][Date Next] [Chronological] [Thread] [Top]

backend glue overlay

Well, the glue overlay basically works, but since the current overlay framework doesn't intercept the tool entry points, the glue code still intercepts those directly. I suppose for completeness' sake we should have the overlay framework intercept everything. Yes?

Meanwhile, it still seems that you need separate syncrepl providers (and consumers) for each database in a glued tree. I guess that's OK; presumably if you split the tree due to size constraints in the first place, the same constraints would exist on the consumers anyway. In order to unify everything under a single provider, the glue overlay would also need to intercept all write operations. Right now it only intercepts searches. I guess it wouldn't be a big deal to also intercept the writes.

I'm also wondering about whether certain overlays should always be enabled by default. Since syncrepl support was hardcoded into back-bdb before I've left its default to "yes" in configure. Will probably do the same for the glue overlay.

By the way, I noticed a mistake in the existing backglue's search order; the intent was for it to always execute searches top-down but in fact it searches the top/root context first, and then does the other contexts bottom-up. The glue overlay does it "right" but the test data sets were created for the "wrong" order so test011/test012 using the overlay report failures/differences.

 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support