mmerickel / pyramid_services Goto Github PK

Sometimes it might be convenient to use other services when implementing a new service.
Is this a good approach and are there any possible problems associated with it?

One issue I ran into with your dbsession service example (that uses a service factory) is the following:

When looking for the service different sessions are returned depending on the context. This is by design. Citing the documentation:

The factory will be used at most once per request/context/name combination.

Having different DB session in one request is quite ugly and I can think of no use case for it. How did I end up with different contexts? By using the request object outside a view function invoked directly with pyramid.threadlocal.get_current_request . In that case the context is None.

This example by Jon Rosebaugh - What the Zope Transaction Manager Means To Me (and you) would work but I wanted to use pyramid_services (for consistency, because I'm already using it in other parts of the application).

I'm aware that this might not be the place for this since it classifies more as a question than an issue, but you could at least fix the example to be more clear that

request.find_service(name='db')

will return different sessions depending on the request context.

My workaround is to always pass context=None:

request.find_service(name='db', context=None)

Is there a simpler solution (e.g. a singleton per request)? register_service() would register a singleton object for the whole application, but I do want a different DB session for every request.

I've tried a few ways to make this work but so far without success. It sure would be nice for non-zopey-people though.

Currently this assumes that the only use of looking up services will be inside of a request context. This is certainly the most common case but I have a case where It would be beneficial to be able to look up the registered service when I don't have a request (such as in an async worker or in a batch script).

Looking at the implementation, it appears that even for already created services (e.g. register_service) a dummy factory is created which does nothing but return the already created service. So I think for this to work, when you're not operating inside of a request, then request would be set to None.

I've copy/pasted the find_service function into my own app to see if I can make it work, and this appears to work:

def find_service(registry, iface=None, context=None, name=''):
    if iface is None:
        iface = Interface
    if name is None:
        name = ''

    context_iface = providedBy(context)
    svc_types = (IServiceClassifier, context_iface)
    svc_factory = registry.adapters.lookup(svc_types, iface, name=name)
    if svc_factory is None:
        raise ValueError('could not find registered service')
    # We are not operating in the confines of a request, so we'll pass a
    # None for the request.
    return svc_factory(context, None)

I'm not sure what the best API would be for using this outside of a request context, I originally thought that a config directive like config.find_service() would work, but the #pyramid IRC channel didn't seem to think that was the right way to go. There's no cache that'll return the same object for multiple find_service calls with this, since there is no request/response cycle to tie the lifetime of that cache to.

Thoughts? Is this something that would be useful to have inside of pyramid_services or should I just keep a copy of my find_services function inside of my app?

For the test setup, I usually config.include() the main application includeme() and then config.include test stuff, to override some of the services/utilities.
It's less intrusive, test code is clearly isolated.

I really like pyramid_services. It's neat and clean.
However it's not possible to "override" a service (same context, name).

How do you test the application if some service must be swapped with "test" service ?