Regarding the actual "following through" on the deprecation: If I understand correctly, the linearstore ORM code relies on classes from the Berkeley DB library; with legacystore gone, the only purpose of the dependency on BDB would be for this mapping even though BDB storage would no longer be in use anywhere. The current-day upshot of this is that BDB is required even if linearstore is the only store included in the build.
It would be nice if this dependency on BDB from linearstore could be removed as part of the deprecation of legacystore; the only problem is that this increases the complexity of the task by an order of magnitude and means that quite some refactoring will be required to the relatively stable linearstore code, which then might not be quite so stable. Perhaps there's a more acceptable migration path that would achieve all goals and also maintain QA? Apologies if I'm harping on about an already well-known issue. On Fri, 8 Jun 2018 at 18:01, Kim van der Riet <kim.vdr...@redhat.com> wrote: > On 06/06/2018 01:04 PM, Robbie Gemmell wrote: > > Seems reasonable. I assume you mean warning at startup only if they > > are actually using the legacy store. > > Yes, correct. Sorry I was not more clear. If the legacystore module is > loaded by qpid, then a warning-level deprecation notice will appear when > it is initialized. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
