Gavin Henry wrote:
Pierangelo Masarati wrote:
Then next on my list is to add a local db search to translucent.c so you can search for attributes not just on the remote db.
I think this was already discussed. I think a big issue about that is that with complex filters (even with simple, if part of the values is local and part remote) need local + remote data knowledge at candidate selection. As a consequence, there's no (simple) way search candidates can be selected if part of the filter relies on local data. I don't see this an easy task from a theoretical point of view, not just in terms of implementation. For example, this is basically what prevents back-meta from building entries by joining partial entries residing on different remote servers.
Ha! A bit ambitious of me then I think. I should have realised if it was simple enough, it would have been done.
Yes, we spent a bit of time on this already. It's feasible to separate the filter into a local and remote part if you configure a list of local-only attributes. But joining the two result sets requires double the memory; you must keep a sorted list of both search results and join at the end.