How would you go about creating a new ObjectContext in framework code; i.e. in code that doesn’t know anything about the environment it’s running in?
> On 14. feb. 2016, at 14:16, John Huss <[email protected]> wrote: > > It's your responsibility. > > You can't get the runtime that way, but you probably don't need to (except > for your existing code!). The injector has everything you'd need except the > runtime itself. > On Sun, Feb 14, 2016 at 8:02 AM Hugi Thordarson <[email protected]> wrote: > >> Thanks John, I had no idea getThreadObjectContext() existed. Does Cayenne >> somehow manage this variable or is it solely my responsibility? >> >> It isn’t quite exactly what I’m looking for, though—ideally, the method >> I’m looking for would be named getProcessServerRuntime(). >> >> Would CayenneRuntime.getThreadInjector().getInstance( ServerRuntime.class >> ) return the currently operating ServerRuntime? >> >> - hugi >> >> >> >>> On 14. feb. 2016, at 13:50, John Huss <[email protected]> wrote: >>> >>> If you just need a context and not the runtime you can use: >>> >>> BaseContext.getThreadObjectContext(); >>> >>> as long as you bind one to the thread earlier. >>> >>> Or you can use the thread injector to get other stuff like an >>> EntityResolver, or also a context, if you've bound it to a thread: >>> public static ObjectContext newObjectContext() { >>> ObjectContextFactory factory = >>> >> CayenneRuntime.getThreadInjector().getInstance(ObjectContextFactory.class); >>> return factory.createContext(); >>> } >>> >>> >>> On Sun, Feb 14, 2016 at 7:19 AM Hugi Thordarson <[email protected]> >> wrote: >>> >>>> Hi all. >>>> >>>> In almost all of my Cayenne projects, I have a class that holds my >>>> ServerRuntime and creates ObjectContexts from that ServerRuntime; sort >> of a >>>> central station for my DB connectivity. Works fine, but it means my >> code is >>>> somewhat tied to that runtime and calls to >>>> MyCentralCayenneClass.newContext() are littered all over the place. >>>> >>>> I’m currently writing a lot of unit tests and these use a separate >>>> ServerRuntime with a different configuration that connects to a test >>>> database. But since some of my code is directly creating contexts from >> the >>>> other ServerRuntime (which connects to the production DB) I end up with >>>> unintended consequences. Same thing for framework code that’s supposed >> to >>>> be reusable—how should it obtain ObjectContexts without knowing anything >>>> about the currently active ServerRuntime? >>>> >>>> I see several solutions to the situtation but I wanted to start out by >>>> checking if there’s a canonical method of solving the problem? (I >> believe >>>> I’m actually asking if there’s a way to obtain something like a global >>>> currently active ServerRuntime, that can be used by reusable code and >>>> tests. But I didn’t want to frame the question in the wrong way >> creating an >>>> XY Problem) >>>> >>>> Cheers, >>>> - hugi >> >>
