A good way to store data that should not be manipulated by the end-user?

So basically this question comes from the huge evolution of minigames.
I’ve created many minigame plugins in the past and I wish to continue to do so on-top of Sponge. I have a thread dedicated to the new and upcoming minigames I plan on releasing here.

So, let me go into a little more detail about my question using minigames as an example.
My idea is to create class files which resemble arenas, however I plan on using the same system for storing arena data across all of my minigames to help prevent code duplication and hopefully speed up productivity in the long run.

So my idea was to simply utilize Google’s JSON library (Gson) to store and then later parse. This would allow me to instantiate arena objects by simply parsing the JSON data. Now this is all good, but is it the best way to go about doing things?

How would you do it?

Depends on the needs. You say you need a way to store and access data across arena objects in an implementation independent way. Using JSON seems to fit your situation as you can push it to be parsed by web, you can store it in SQL/NoSQL/JSON files etc and in-memory with JSON objects.

I personally only see the need to do this if say you wanted to make a web-panel to edit values in a future-proof way (without hard-coding value editing per-game). Although if you only used flat-file arena configuration locally, I would stick with the classic inheritance arena object model and not bother.

If you’re storing it as Json, I’ll assume that the only accessor will be the server (eg, you won’t be trying to grab this information using SQL for a website).

If the above is true, you can just use the DataAPI to attach data to the player. It’ll be stored on its own through the implementation.

1 Like

How would that work with manual editing? Where is the data actually stored on the drive (from DataAPI)?

I don’t think there is a best way. There’s some things you should avoid (e.g creating you’re own format) but there’s one way and another way.

If you don’t want the data to be manipulated by the end user using an SQL storage could be a way.

Sorry, they’re just config files, but they only store data that should be set via commands, and not edited manually, like arena spawn locations for example.

Then why not just use a disclaimer informing users they should prefer using the in-game commands? If you make it user-friendly enough they will most likely prefer it anyways, although there will always be people who would rather manually edit the file.

If they’re not manually edited, then just apply the data to the players using the DataAPI. Problem solved, and very little extra work for you.

1 Like

I don’t think you understand :stuck_out_tongue:
This is for my server, privately :smiley:

I am just curious if it’s a good way of doing things.

Why… does your server being private matter? Using the DataAPI doesn’t suddenly open-source your code or make it public, or anything lol.

1 Like

No… ^^ that :stuck_out_tongue:

It showed up in my notifications that you replied to me. ;_; lol

If it’s a private plugin and not something you’re distributing to be used on other public/private instances then I see no point in doing so. The only people who should have access to your files should know what they’re doing and therefore creating a system in which they can’t shouldn’t edit the data directly (flat-file/sql etc) is a waste of time.

1 Like

Ughh, I’m not concerned about that… it was just an example. I’m just asking what’s the best way to go about storing data haha

Simple answer? None.

There is no “best” way. The question should instead be, “This is my system, here’s my data, this is how often and how I need to read/write my data, how should I store it?”

EDIT: For your situation, if you use a remote database I would go with that. This way you can add web integration down the road, you don’t have to worry about the files being lost. Doing it in a central database is great for big networks as you can update all servers simply by changing the values in your database instead of uploading a new .json file to all server instances.

1 Like

Okay, I’ll take that into consideration, thanks @wingz

Yeah buddy. If you have any issues when you’re working on your data storage post what you have and relatively how you would like to access it so that we can help you specific to your system.

1 Like

If you need it to be cross server definitely look into a SQL database or redis depending on whether the data is relational and needs to be indexed.

If you just need a quick and dirty storage for data relating to players/entities/tile entities that doesn’t need to be indexed, that you only need when the player/entity/tile entity exists and is loaded (you can use Users for players that arn’t loaded) Then just make a custom data manipulator. It’s not worth the hassle of doing everything else if all you are storing is the last time a player used /home or whether they are currently a vampire.

If you don’t need cross server stuff, but do need it indexed I’d still look into using SQL Just maybe use a local h2 file as the backing file instead as that gives you a clear migration path.

But users really really appreciate being able to edit the files directly, you might even come into a situation yourself where it’s quicker to edit the file then it is to boot a server up and edit it. For data relating to worlds and maps I’ve seen json and xml both used to good effect, marking out regions / flag location etc.

But don’t discount the DataAPI it’s a vastly powerful tool and with the new Value changes it’s going to be much less verbose then it was previously.

Side question: Are custom DataManipulators implemented yet?

As of this WIP PR being merged. Yes. https://github.com/SpongePowered/SpongeCommon/pull/94

1 Like