{"action":"opened","issue":{"url":"https://api.github.com/repos/jdbi/jdbi/issues/1382","repository_url":"https://api.github.com/repos/jdbi/jdbi","labels_url":"https://api.github.com/repos/jdbi/jdbi/issues/1382/labels{/name}","comments_url":"https://api.github.com/repos/jdbi/jdbi/issues/1382/comments","events_url":"https://api.github.com/repos/jdbi/jdbi/issues/1382/events","html_url":"https://github.com/jdbi/jdbi/issues/1382","id":394901833,"node_id":"MDU6SXNzdWUzOTQ5MDE4MzM=","number":1382,"title":"@CreateSqlObject and Jdbi.onDemand() do not play nice with each other","user":{"login":"qualidafial","id":38629,"node_id":"MDQ6VXNlcjM4NjI5","avatar_url":"https://avatars2.githubusercontent.com/u/38629?v=4","gravatar_id":"","url":"https://api.github.com/users/qualidafial","html_url":"https://github.com/qualidafial","followers_url":"https://api.github.com/users/qualidafial/followers","following_url":"https://api.github.com/users/qualidafial/following{/other_user}","gists_url":"https://api.github.com/users/qualidafial/gists{/gist_id}","starred_url":"https://api.github.com/users/qualidafial/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/qualidafial/subscriptions","organizations_url":"https://api.github.com/users/qualidafial/orgs","repos_url":"https://api.github.com/users/qualidafial/repos","events_url":"https://api.github.com/users/qualidafial/events{/privacy}","received_events_url":"https://api.github.com/users/qualidafial/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-12-30T21:14:04Z","updated_at":"2018-12-30T21:14:04Z","closed_at":null,"author_association":"MEMBER","body":"Users intuitively expect that if you call a `@CreateSqlObject` method on an on-demand SQL object, the returned SQL Object should also be on-demand. In reality:\r\n\r\n- If you call the method from _outside_ the SQL object, the returned SQL object will be unusable, since it's connection is closed.\r\n- If you call it from _inside_ another method of the SQL object, it is attached to the same connection, and remains usable within the scope of that method call.\r\n\r\nThe fact that it doesn't behave as expected is a usability problem which keeps getting reported over an over.\r\n\r\nThe root of the problem is that `Jdbi.onDemand()` is implemented in core using proxies. When you call a method on an on-demand object, it is effectively calling `jdbi.useExtension(Dao.class, dao.callMethod())`. The implementation is agnostic to the implementation of SQL objects, let alone the `@CreateSqlObject` annotation.\r\n\r\nI have some ideas on how we can improve this:\r\n\r\n- Push the `onDemand()` feature into a new default method in the `ExtensionFactory` interface (maintains backward compatibility).\r\n- Override the `onDemand()` implementation in `SqlObjectExtension` and expose the on-demand status through the API somehow. Maybe an `OnDemandSqlObject` interface, or something?\r\n- Modify `@CreateSqlObject` handler to produce an on-demand or attached DAO based on whether the callee is on-demand or attached.\r\n- Throw exceptions for bad usage with informative messaging\r\n  - Calling `getHandle()` from outside an on-demand SQL object. Send them to `useHandle(...)` or `withHandle()` instead.\r\n  - Calling `Transactional.begin()`, `rollback()`, or `commit()` from outside an on-demand SQL object. Send them to `inTxn()` or `withTxn()` instead.\r\n  - Any other bad usage we encounter\r\n\r\n@jdbi/contributors thoughts?"}}
{"actor":{"display_login":"qualidafial"}}