On 09/18/2016 01:01 PM, Thomas De Schampheleire wrote:

On Sep 18, 2016 12:28, "Alessandro Molina" <alessandro.mol...@gmail.com <mailto:alessandro.mol...@gmail.com>> wrote:
> If I remember correctly kallithea explicitly handles commits, so probably it has no need for the transaction manager. > Try to add base_config['tm.enabled'] = False in app_cfg.py and see it everything still works as expected and the error disappeared.

Thanks, I will try that.
Do you have more details about this transaction manager? Which package normally supplies this, how does it work?

(I guess it is as mentioned on https://turbogears.readthedocs.io/en/development/reference/upgrading.html#transaction-manager-is-now-an-application-wrapper )

Would it replace existing calls to Session.commit(), or is it not as simple as that? And finally, in your opinion, is it better to use Kallithea's current approach, or consider using transaction manager?

I think that is related to an outstanding issue from https://bitbucket.org/conservancy/kallithea/pull-requests/249/activate-vcs-opertations-tests-v4/diff , as discussed on https://bitbucket.org/domruf/kallithea/commits/06f66664f210ffed83a4b52a07528000572cc9a1?at=default#comment-3676506 . We need better control over our database transactions.

It would probably be a good idea to move towards having HTTP requests and database transactions tied closely together. Kallithea is however not there yet, so I guess this 'tm' should be disabled for now. (Looking at AppConfig, we should perhaps use 'minimal'? I don't know if it is better to rely on things "being taken care of" (but where we still have to know what is being taken care of and how it works), or if it is better to be more explicit.)

kallithea-general mailing list

Reply via email to