Make caching optional?

[hynek]

Should there be a way to force a new value either at factory level or at get() level – or both?

[elfjes]

I would say this is primarily a factory-concern. Use case that springs to mind is have a (connection) pool where you have a pool in your container and can with container.get(Connection): where the factory for Connection obtains one from the pool. as a consumer, you don't want be bothered with details of whether it should be cached or not.

So perhaps both? "As a consumer of a service, I want to be in control of the life time of that service"... nothing springs to mind, but perhaps that is my (lack of) imagination

[hynek]

to clarify, the caching i'm speaking about is that if I ask for a connection, it is stored in the container and returned to everyone who asks for it too. the factory is not involved at all.

this is usually what you want – at least I haven't run into examples that want the opposite. it can be problematic to have two database connections for example and try to combine them into one transaction.

---

to make this the job of the factory, the factory would need the container. Even if we keep the short path within container, you'd have to write something like:

def factory(svcs_container):
    x = create()
    svcs.container.store(x)
    return x

Which would make it the wrong thing by default, which is not what I want.

I could live with having store/cache on the container, but only require it when the user called register_factory(Foo, foo, cache=False) and opts into taking care of that themselves.

But as said, I have not really needed this yet, so I think it's better to wait for people yell at me for something like this.

[elfjes]

Right, I didn't express myself correctly. What I meant is that in general it is at registration time that you'd want to specify whether containers should cache an instance:

registry.register_factory(int, lambda: 42, cache=False)

and not at request time:

container.get(int, cache=False)

I can think of use cases for the first (see previous reply), but not for the latter

[hynek]

Ah right!

TBH my uses for the latter would be mostly hacky things in testing. But let's wait and see for now.

[jamie-at-arkifi]

I do have a use-case for this: transactions and sub-transactions.

If the app defines a transaction as a service (and the factory handles things like commit/rollback), you could have it return a new (sub) transaction in each use. (The cool thing about this that I think the state of the database would be consistent with Python exception handling.)

(Although I also suspect that with the oddities you can find in transactions shenanigans, you're better off just... not.)

[hynek]

As someone who has just written a generic transaction manager/UoW factory 😅 I would agree that the intricacies of transaction management might be a bit more complex and supporting that would lead to an attractive nuisance that I’m really trying to avoid to create 🤔.