Feature description

I'd like an option to disable saving of userdata files, preferably with a single boolean toggle, enabling it would stop the generation of userdata yaml files.

How the feature is useful

Some server network setups don't really need to persist Essentials userdata because they use EssentialsX mainly for its large command palette. They don't use the jail system or the economy part, etc. Instead, they use a cross-server currency system with a database. I want an option to disable saving of userdata files as this could save on disk space and probably on disk I/O as well.

If you don’t need EssentialsX to do anything, why use EssentialsX? What exactly are you using essx for if you’re not saving userdata.

If you don’t need EssentialsX to do anything, why use EssentialsX? What exactly are you using essx for if you’re not saving userdata.

In my setup, nearly everything that the plugin saves in these yaml files are just there for no reason. We use EssX for the command palette, not for jail, nor muting or banning players, etc. The problem with just removing the plugin alltogether is that Essentials is so common among staff members it is almost muscle memory so losing these would be inconvinient. I know that Essentials supposed to be a '"one plugin does it all" system when it comes to most server functions but it I think it was never meant to be used on server networks it is more like a "single server, all important functions" type of plugin. But it was adopted by many networks anyway.

Not an EssX dev here, just thinking. How big is your userdata folder, that you're worried about space? Similarly, IO should be tiny on this. It feels, at first glance, like this is microoptimization.

I'm not opposed to this option on principle, but I also don't see much of a compelling reason for us to support this. EssentialsX stores very minimal data on disk and does almost no reads/writes unless you use features that persist data (jails, homes, mutes etc). Any change to disable creating userdata files would require thorough testing, as this may have unforeseen consequences for commands that do expect persistent data.

Not an EssX dev here, just thinking. How big is your userdata folder, that you're worried about space? Similarly, IO should be tiny on this. It feels, at first glance, like this is microoptimization.

Currently the server in question is in development so not that big for now but imagine a network with let's say 1000+ players and Essentials is installed on every backend paper server so it creates a yml per player and per server for each and every one of them.. To me, that somehow sounds terrifying

Just Google Chrome has over 30 000 individual files stored in my AppData folder! None of this feels concerning. :)

I like the simplicity of having yaml files, however, I do support the idea of essentialsX being able to store user data in a mysql database (optional, ofc - could be a config setting) <3

I like the simplicity of having yaml files, however, I do support the idea of essentialsX being able to store user data in a mysql database (optional, ofc - could be a config setting) <3

MySQL is not relevant to this issue. See #1265

If I understand correctly, EssX uses yml more like a backup so some state and location data could be restored upon next server startup. To me, this sounds like Essentials reinvented Redis with persistence :)

I like the simplicity of having yaml files, however, I do support the idea of essentialsX being able to store user data in a mysql database (optional, ofc - could be a config setting) <3

Yes yml is simple because you can edit things by hand easily but when you have a dozen players and multiple servers, this simplicity becomes pointless. I think Yml was never intended to be a data store, it was created for configuration.

I like the simplicity of having yaml files, however, I do support the idea of essentialsX being able to store user data in a mysql database (optional, ofc - could be a config setting) <3

MySQL is not relevant to this issue. See #1265

Ok, didn't know MySql was flat-out rejected 8+ years ago.. Duh, silly me. :) However, a database would be relevant to this issue regarding disk i/o ..

Reduced Seek Time: Databases are optimized for storing and retrieving data efficiently. They employ techniques to group related data together on the disk, minimizing the time it takes for the disk head to locate the desired information (seek time). With separate YAML files, the disk head would need to jump around a lot more to find specific user data.

Caching: Databases often cache frequently accessed data in memory, allowing for much faster retrieval compared to constantly reading from disk. This caching becomes less effective with scattered YAML files.

Batching: Databases can handle multiple read/write operations in a single batch, reducing the overall number of disk accesses needed. With YAML files, each user data access would require a separate disk operation.

Data Organization: Databases are designed for structured data, allowing for efficient querying and filtering. YAML files wouldn't offer the same level of organization and searching capabilities.