Currently the database implementations are doing some business logic, such as ensuring a guild exists on methods such as "insert_ticket_panel", "insert_thread", "set_guild_setting_value", "upsert_monitor", "insert_audit_log", and "insert_ticket".
The reasoning for this is that these entities have foreign keys refs. to the Guild entity which makes insertion throw errors if we've not instantiated a guild object. However, having this logic on the database adapter layer is silly.
The database adapter should get, delete, update, and create data and nothing more. Functionality such as ensuring guilds should instead live on the service layer (such as GuildManager).
Low prio, but should be adressed.
Currently the database implementations are doing some business logic, such as ensuring a guild exists on methods such as "insert_ticket_panel", "insert_thread", "set_guild_setting_value", "upsert_monitor", "insert_audit_log", and "insert_ticket".
The reasoning for this is that these entities have foreign keys refs. to the Guild entity which makes insertion throw errors if we've not instantiated a guild object. However, having this logic on the database adapter layer is silly.
The database adapter should get, delete, update, and create data and nothing more. Functionality such as ensuring guilds should instead live on the service layer (such as GuildManager).
Low prio, but should be adressed.