Great idea! I had forgotten that I could create a separate ServerRuntime now. Yes, that would work fine in my case. The overhead isn't an issue in this particular case.
That is one of three cases where I now use DataContextFilter, and definitely the one that I would most like to get rid of as it's the most complicated one. The second case is where I force a testing failure, but I can use DataChannelFilter.onQuery() as a replacement. The third case is new, due to a change in behavior between 1.1 and now (I think the change happened in 1.2). I could probably use a DataChannelFilter here too, or I could also use a custom ServerRuntime to fix this one, but I'm hoping that we can treat this change as a bug and fix it instead. I'll start a separate thread to discuss this one. On Tue, Sep 24, 2013 at 2:04 PM, Andrus Adamchik <[email protected]> wrote: > > On Sep 24, 2013, at 8:48 PM, Andrus Adamchik <[email protected]> wrote: > >> he "special DataContext" case where the qualifier should be ignored can >> probably be handled by starting a separate ServerRuntime, where you can >> strip off the qualifiers. For whatever overhead it creates (ideally not >> much), this has an advantage of cleanly separating "spaces" with different >> ORM rules. > > Elaborating on this a bit… The old Configuration allowed multiple > DataDomains, each of those requiring its own DataMap(s) saved in the project > upfront. Good idea, but hard to use in practice. > > ServerRuntime (with single DD each) is more user-friendly. By starting > multiple independent runtimes you to easily reuse a single mapping project, > tweaking each in-memory copy local to each Runtime (as well as tweaking other > parameters like cache). 2 Runtimes can reuse a single DataSource (JNDI, or > otherwise), etc. > > Andrus >
