Optionally specific tables per skill

Description

Let’s suppose I have two skills that have different functions on one opsdroid instance, both using the memory module with a DB.

At the current time, the data from each of those skills are mixed together, which is messy and quite gross. If one looks at Errbot, for example, every skill has its own db (a python shelve, iirc).

If I have a bot that’s got 2 skills, one that saves links sent, another that saves quotes of amusing messages, why should those values be in the same table?

If I have the amusing quotes in a nice table, I can use those quotes for other purposes entirely outside of opsdroid too without contamination. While it’s possible to avoid this by making the skills say prepend skill_name to the key stored, that would require everyone who writes a skill to do that. Allowing custom tables avoids that impossible request.

Likewise, we cannot control how everyone writes their skills. It might be possible the values intended to be saved by one skill can overwrite values intended to be saved from another skill.

Expected Functionality

1. DB connector configs should have options for
   1. DB name
   2. default table/collection name - if applicable
2. Memory’s get and put args should have **kwargs to accept, optionally defined in db modules, a table_name= kwarg. If not specified, it uses the default table.
3. This allows skills in their conf to give open for a table name to use for that skill, or multiple tables, if it is a complex skill.

Experienced Functionality

Explain what happened instead(Please include the debug log).

Versions

• Opsdroid version:
• Python version:
• OS/Docker version:

Configuration File

Please include your version of the configuration file below.

# Your code goes here.

Additional Details

See #1805 read the new documentation - it has a test skill. Also see the changes to memory and how get and put are defined in the postgres connector. Also see #1799

[jacobtomlinson]

This is a “yes and” situation. The kwarg that you’ve done already is fine, and it would be great to see a follow up which adds a context manager too.

[dud1337]

but my main comment would be whatever we do here it would be nice to have it apply to all the database modules rather than having the skill have to worry about which one is configured underneath.

Wouldn’t be happy any other way.