There are plans to integrate FastDataStore as a better system, as a package for DataStore+, as of now, DataStore+ is a datastore package handler.
However, it will be a very, very limited and strict system when it comes to caching.
The use of this is discouraged, therefore I removed the download link.
Update:
fastDataStore:GetFromCache(key, dsName)
This function ignores if the data is old. This retrieves info from cache, and that’s it. If you wanna care about if the data is not really recent, then you can use :Get()
This function also does NOT actually consult data stores, as long as theres data inside, it will be returned;
This is very nice and easy to use.
FastDataStore can be used for PlayerData, I didn’t see any problems with it, though I would recommend for simpler stuff like Player Settings;
Your module relies on MessagingService, rendering it pretty much useless. You linked the wiki link, where it clearly says this:
DataStore:GetAsync every 20 seconds, which you already do with MessagingService (in your code: if data.timeSaved >= (os.time() - 20)).
It’s just to make data store requests faster, any time something goes wrong it uses data stores, and it only caches it when it’s already saved on a datastore, but good point I guess.
Update: Cache now gets wiped if the data is old enough; Also some bug fixes.
No? MessagingService does not ask for data, that’s just a check to make sure the data is recent enough. If it isn’t it will remove the cached version so that it uses the datastore instead.
Wouldn’t this be problematic if the data exceeds 1kb in size? As the message limit for MessagingService is just 1kb?
Have you thought of encoding the data with Base64 before sending the data to the rest of the servers, or use any sort of compression method to compress the data into a much smaller size?
A repository to a Base64 implementation in pure Lua can be found here: GitHub - iskolbin/lbase64: Lua base64 decoder/encoder
Imma look into that, didn’t even remember, shouldn’t be too hard
I know profile service, but I don’t think it’s related to what I’m trying to do here.
Huge update:
:Set() has been removed for compability reasons
Now you can specify a player in :Get(key, dsName, plr). That will try and use versioning to make sure you’re not overwriting data, just remember that you should be using this module for that anyways, there’s also versioning when possible for normal data on which plr isn’t specified. But that is a not recommended method.
Bug fixes
Probably a bunch of bugs introduced, try to test it to make sure everything it’s working. Report it to me if possible.
Btw, as a bump to you know, notify people, I recently updated the module, some bug-fixes and a new feature.
This new feature is:
This as noted here:
Works with Messaging Service. It uses the same requests that are used to cache to other servers.
And when it’s for the same server, it’s near-instant.
Also, for some reason I forgot to specify module:GetFromCache(). Though I think it’s better that way, as the data gets wiped on cache when it’s expired anyway. Resulting on it returning nil.
ProfileService is hard to manage and hard to understand. It’s A GREAT module, but if you’re starting out, it’s kind of horrible. The functions names are a bit huge, and it’s just annoying at times.
Please read the statement above:
Unless you’ve gotten rid of that, (which you might have) this isn’t very useful as it’s not reliable. I’d suggest reworking this as the idea of simplicity is nice but what’s currently here simply can’t be an alternative to Datastore2 or ProfileService.
That is debatable. I learned the basics of Profile Service in less than 5 minutes. In my opinion, the documentation is well written and it doesn’t take too long to understand/learn it.
Yes, I know, but I mean for people who don’t understand datastores easily. Yeah.
Well, once again, that is debatable. Someone I know was able to learn how to use Datastores and Profile Service in an hour and he just started learning to code.
Here’s one thing that drives me mad, any-time anyone makes a DataStore wrapper/module, someone will say, “Why is this better than DataStore2?” And as I said:
It isn’t.
It doesn’t need to be better than neither of these; That makes smaller developers who don’t understand Luau that well become unmotived to share their amazing tools sometimes.
I understand that this is not a GREAT module, but for certain stuff, it can be useful, for example, player settings, which don’t need to have that much security on them, it’s just settings, and if you ended up using a separate datastore, and you don’t wanna have that many requests, just because of that, this module will convert everything, and cache those, and have less requests to these. Also I won’t remove MessagingService from this, this is the MAIN thing about this module, it USES MessagingService as a “little help” to make requests faster; but mainly uses normal DataStores, in fact, this module has changed ALOT, to make cached data from other servers have STRICT, like VERY strict, rules about it. It needs by default, to be NEWER than 600 seconds (10 minutes) (you can chance this to anything;), to use it from caching. Else it gets it from DataStores. I know MessagingService isn’t about keeping player’s data, but it isn’t even doing that in a deep way. I try to use DataStores here as often as possible in a way that MessagingService can STILL be useful.
Hm, this is interessing I actually didn’t notice Roblox said this:
And by the way, if you DON’T want caching you can just decrease the amount of time that the CleanUp loop takes to re-check and make the Expire Time very low. Like 1 second. That should “disable it”, I think I might just make something like that. But since the module is so INTEGRATED into this system, it’s a bit annoying, but I will try.
