Change Details

Follow-up from {T236880}. These two methods take the same arguments, and return the same logical object, and of the exact same type (DBConnRef). The only difference: * `getConnectionRef` will pre-connect to the underlying database, thus the `DBConnRef` is only providing automatic re-use once out of scope. * `getLazyConnectionRef` lets `DBConnRef` auto-connect upon first relevant method call, and also provides the same automatic re-use once out of scope. From what I can tell, deferring the connect call is not expensive, and the `__call()` overhead for auto-connecting is present in both cases as well. Would it make sense to change `getConnectionRef` to also be lazy, and then phase out `getLazyConnectionRef`? Is there a use case from a feature/product perspective of where code wants to preconnect to get a desirable change in behaviour or some other benefit?

Follow-up from {T236880}. These two methods take the same arguments, and return the same logical object, and of the exact same type (DBConnRef). The only difference: * `getConnectionRef` will pre-connect to the underlying database, thus the `DBConnRef` is only providing automatic re-use once out of scope. * `getLazyConnectionRef` lets `DBConnRef` auto-connect upon first relevant method call, and also provides the same automatic re-use once out of scope. From what I can tell, deferring the connect call is not expensive, and the `__call()` overhead for auto-connecting is present in both cases as well. Would it make sense to change `getConnectionRef` to also be lazy, and then phase out `getLazyConnectionRef`? Is there a use case from a feature/product perspective of where code wants to preconnect to get a desirable change in behaviour or some other benefit? >>! In T255493#7747794, @Krinkle wrote: > Strawman proposal: > > [x] Make `getConnectionRef` do lazy connections by default. I'm not aware of cases where an eager connection is useful (whether for correctness or perf/stability etc). If such use case does come up that we missed (perhaps @aaron knows), then assuming they are rare, perhaps we can expose a "connect" method so that people can simply do getConnectionRef and then connect in order to get the eager connection they want before passing the connection around. Seems simple enough. > [x] Deprecate and remove `getLazyConnectionRef`. > [x] Make `getConnection` an alias for getConnectionRef, and turn `reuseConnection` into a deprecated no-op. Internally we'll move the code in reuseConnection to a different `@internal`-only method for DBConnRef to continue to use. > [ ] Remove reuseConnection. > [ ] Soft-deprecate getConnectionRef with no intention to remove until at least 2 LTS'es later. It's a commonly used method for a good reason, let's not have another major breaking churn here and keep it as a simple alias.

Follow-up from {T236880}. These two methods take the same arguments, and return the same logical object, and of the exact same type (DBConnRef). The only difference: * `getConnectionRef` will pre-connect to the underlying database, thus the `DBConnRef` is only providing automatic re-use once out of scope. * `getLazyConnectionRef` lets `DBConnRef` auto-connect upon first relevant method call, and also provides the same automatic re-use once out of scope. From what I can tell, deferring the connect call is not expensive, and the `__call()` overhead for auto-connecting is present in both cases as well. Would it make sense to change `getConnectionRef` to also be lazy, and then phase out `getLazyConnectionRef`? Is there a use case from a feature/product perspective of where code wants to preconnect to get a desirable change in behaviour or some other benefit? >>! In T255493#7747794, @Krinkle wrote: > Strawman proposal: > > [x] Make `getConnectionRef` do lazy connections by default. I'm not aware of cases where an eager connection is useful (whether for correctness or perf/stability etc). If such use case does come up that we missed (perhaps @aaron knows), then assuming they are rare, perhaps we can expose a "connect" method so that people can simply do getConnectionRef and then connect in order to get the eager connection they want before passing the connection around. Seems simple enough. > [x] Deprecate and remove `getLazyConnectionRef`. > [x] Make `getConnection` an alias for getConnectionRef, and turn `reuseConnection` into a deprecated no-op. Internally we'll move the code in reuseConnection to a different `@internal`-only method for DBConnRef to continue to use. > [ ] Remove reuseConnection. > [ ] Soft-deprecate getConnectionRef with no intention to remove until at least 2 LTS'es later. It's a commonly used method for a good reason, let's not have another major breaking churn here and keep it as a simple alias.