12.json (3790B)
1 { 2 "number": 12, 3 "title": "Add support for shared global state (similar to Actix's web::Data) ", 4 "state": "open", 5 "author": "donicrosby", 6 "created_at": "2022-03-12T06:12:42Z", 7 "closed_at": null, 8 "labels": [ 9 "enhancement" 10 ], 11 "assignees": [ 12 "MTRNord" 13 ], 14 "body": "I've been working on a bot that has some commands that requires a database connection in order to hold some state across restarts.\r\n\r\nWhile having the config being passed is fine for stateless bots. Anything that would require a long running connection it wouldn't be efficient to connect to the database every single message. It would be a huge improvement if there was a way to have a single state store that is stood up at startup that can be accessed by all of the commands.\r\n\r\nThe current config type must have serialize and deserialize which doesn't work for something like a DB without a huge hack of making a custom deserializer that stands up the DB connection to be stored in the config (if that's even possible)", 15 "comments": [ 16 { 17 "author": "MTRNord", 18 "created_at": "2022-03-12T14:39:26Z", 19 "body": "Hm due to the macro currently used this seems like it is quite a lot harder to do as generics wouldnt work as wanted. I am currently trying to understand how actix solved this, as it seems non trivial." 20 }, 21 { 22 "author": "MTRNord", 23 "created_at": "2022-03-12T14:40:05Z", 24 "body": "As `Data<Config<'a>>` in the command handler would conflict with `Data<T>` in the macro" 25 }, 26 { 27 "author": "MTRNord", 28 "created_at": "2022-03-12T14:42:43Z", 29 "body": "To be exact this is the issue the macro currently faces:\r\n\r\n```\r\nerror[E0308]: mismatched types\r\n --> example-bot\\src\\commands\\mod.rs:7:1\r\n |\r\n7 | #[command_generate(bot_name = \"Example\", description = \"This bot prints hello!\")]\r\n | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `config::Config`, found type parameter `T`\r\n |\r\n = note: expected struct `mrsbfh::utils::Data<config::Config<'_>>`\r\n found struct `mrsbfh::utils::Data<T>`\r\n = note: this error originates in the attribute macro `command_generate` (in Nightly builds, run with -Z macro-backtrace for more info)\r\n```" 30 }, 31 { 32 "author": "MTRNord", 33 "created_at": "2022-03-12T14:45:50Z", 34 "body": "It seems we would need something like this https://docs.rs/actix-web/latest/src/actix_web/handler.rs.html#124-153 But that seems restricting. I will check how axum does data passing. Maybe that has a nicer solution" 35 }, 36 { 37 "author": "MTRNord", 38 "created_at": "2022-03-12T14:50:25Z", 39 "body": "It seems the best would be to use a trait approach, where commands implement a trait. Instead of using the proc macro." 40 }, 41 { 42 "author": "donicrosby", 43 "created_at": "2022-03-12T15:06:10Z", 44 "body": "My only issue with that is it would break backwards compatibility, but we are still v0 \ud83d\ude01" 45 }, 46 { 47 "author": "MTRNord", 48 "created_at": "2022-03-12T15:07:39Z", 49 "body": "> My only issue with that is it would break backwards compatibility, but we are still v0 \ud83d\ude01\r\n\r\nI dont think I can not break that while implementing this. But I will try to make it non breaking. Also I likely go more for the way axum does it then actix. As it seems easier to implement :)" 50 }, 51 { 52 "author": "MTRNord", 53 "created_at": "2022-03-12T16:11:54Z", 54 "body": "Also I am trying to still keep the macro and use the traits internally. But the handlers probably will change and possibly also how you init it. But I am still in the experimentation phase and hope to later share a first working iteration. " 55 } 56 ] 57 }