Shared common tables for plugins using databases

Many of my plugins will require a SQL database to work. One thing that bugs me is that many of them have to store similar data or even the same.

Examples: A table that stores an INT primary key, player uuid and player name (same for world), the last login date and the first join date.

I usually use the INT primary key to reference a player (or any other object) in another table, so I will need that table (INT if <–> UUID) for all plugins storing data related to players

Let’s say I have a block logging plugin, a server mail plugin and a plot plugin. They could use the same player table.

It would be great to have a library/plugin that creates and manages these tables for other plugins. Instead of adding new columns to these standard tables, plugins can create their own tables to save their data, but use the INT key of the standard table to reference the player/world/etc.

The library would only create a standard table if at least one plugin requests it (or the admin in a config file), and only create the columns the plugin needs.

Ideas for tables:

Player

  • INT primary key
  • UUID
  • last known username (only if requested, lib tracks username changes)
  • first join date (only if requested)
  • last login date (only if requested)
  • world when last logged out (only if requested)

World

  • INT primary key
  • UUID
  • last known name (only if requested, tracks changes)
  • spawn point (only if requested)

The library listens for player and world events and updates the tables automatically, so plugin developers can concentrate on the unique features of their plugins.

There could also be standard tables for blocks, entities and any other game object.

What do you think?

1 Like

this could all be achieved without a plugin, as long as the shared data in the player tables is changed all they need to do is give an option to set the player table.

That’s right, but I thought it would be easier to outsource certain tasks to a plugin/library.

The idea is that the plugins still work directly with the SQL tables. The library creates an entry when a new player joins (highest event priority), tracks name changes and updates last login dates. Stuff like that.

How would a plugin know that another plugin already updated a login date? That’s the problem (and the library should solve it, by just doing all the work).

events.
you listen to an event to know when to change it, you throw an event when it changes it.

also, depending on how its made, you could just let it all be automated by the one plugin managing the data and have the rest of the plugins either listen for the event it throws or use the plugin’s API to access the data of the table in question.

1 Like

So like Vault in a sense. The main difference being that it is does it own stuff while giving other plugins an interface to what its doing.

i’m not sure what you mean by it doing its own stuff, but i kinda just thought of it as a tracker plugin solely for the purpose of keeping track of all the data its supposed to. the interface is the primary unit of it since its supposed to be a data storage unit for common values. otherwise, yes, like vault in a sense.

Not sure if this is possible to accomplish. But indeed most plugins need these tables to get working.