FutureDatastore

Resources Community Resources
, ,
#26

True, though I’d love to modify our data and have it reflect to me. Pick your poison.

I wish this was possible, would help hiding data which could hide their data from others for a magnitude of reasons, though I want to make sure the client has no authority to modify the universally true data.

I’d assume replicating values are less intensive than replicating every single action a player makes and so on. I’m creating this to work in 100+ player servers flawlessly. The only things which could get intensive is when you have signals connected to them, though thankfully that’s local and not even intensive.

I’ll explain this in the video, though I’m not going to name other resources under the misconception I’m dissing the creators and modifiers of them.

UpdateAsync will rewrite the data. Here’s how it’d work.

  1. Player leaves game, automatically initiating :Save().

  2. Player joins new DataModel, requesting :Get() to Roblox’s API.
    The inaccurate version is obtained, though overridden by the newer version.

  3. Player leaves game, the Module saves old version though is overwritten by the old version resaving.

I’ll be further updating this to account for this going haywire in the case the data saves before the player leaves or in the case the server shuts down and the data cannot be saved within the BindToClose grace period. As a reference, saving takes under 1 second. I’ll consider showing benchmarks in the video.

1 Like
#27

Profile Service is always going to be superior than this in all aspects. Less code doesn’t mean its better. Profile Service is safer, easy, and handles excess data requests.

Btw, when did loleris say that ProfileService isn’t enought?

#28

No GitHub? This really isn’t a proper resource without one.

It isn’t very good anyways. There’s no extra features.

#29

Signal modules exist and are way more reliable.

#30

There was a GitHub. I removed it as no one seem to care about the source code. The next repo will be on the update.

@dutycall11
I’ll be montaging all your replies some places in the video. Do you want me to put your username in it as well? Research orientated purposing.

#31

@loleris Maybe you can fix that and add those as options & features :wink:

1 Like
#32

In my opinion, it would be best if you just close this post / remove the module. The method of turning datastore values into instances is slow and this module is rendered useless by DataStore2 and Profile Service. Don’t reinvent the what doesn’t need to be reinvented

#33

Stop yelling ProfileService, if this module is not something you would want to use then move on.
It’s obvious that it doesn’t work like ProfileService kindly stop pointing out the obvious.

#34

Frankly, this doesn’t seem very professional nor a useful resource.

You begin by calling others “undereducated” which isn’t appropriate, there is no documentation and it’s a bit premature to post this as a resource when it isn’t a stable release.

You say it’s a must have yet it isn’t flexible and lacks basic required features for data saving.

  • It doesn’t use any form of session locking, so it suffers from the same pitfalls as directly using DatastoreService where old data can be loaded when data is reloaded quickly.

  • You access data through the datamodel which makes it more difficult for scripts to interact with the data and uses far more memory than necessary.

  • It automatically replicates all data which again likely isn’t needed in the majority of cases and results in wasted memory and bandwidth.

  • It’s tied to players so it cannot be used for anything else, additionally there’s no way to create different kinds of stores using it, they are all forced to use the same format.

2 Likes
#35

Documentation

First things first, the documentation is nonexistant and if you aren’t a technical fellow you wouldn’t really understand how to implement things, especially when all of the ‘templates’ for the data is within the main modulescript.

Formatting

It doesn’t seem to follow any known style guide which makes it difficult for anyone to read it properly, especially when it doesn’t follow standards.

You claim that the code is ‘Human Readable’ yet there is an absurd amount of whitespace and you don’t use comments to actually describe areas of the code

image
image1045×705 54.1 KB

If I had no knowledge of scripting whatsoever, I would have no idea what ‘Format’ meant, and what the acceptable values are.

The same goes for the settings

image
image2325×259 63.2 KB

Using a massive string as a property is a waste of memory, when you could’ve easily just written a comment or created an attribute on the script and directed people to use that instead.
image

Error Handling

In the likely event that one or all of Roblox’s APIs go down (including DataStoreService) there is almost always an error returned by any/all of the methods you use.

Despite this, you have not used a pcall once in your code which makes it extremely unsafe

image
image907×221 11.8 KB

What would happen if GetAsync failed? The user would have no data and the game would cease to function. There is no retrying or anything that would handle this sort of error

If an instance of data for a player has not been created, what is an external script expected to do? Will it just WaitForChild until it exists? Will it just ignore it? Without using an external API there is no proper way to handle these sorts of issues in other scripts. By simplifying it to be more “Human Friendly” you’ve made it near impossible to handle errors properly in scripts that depend on this data.

Features

There is a lack of features that make this module stand out from just using DataStoreService barebones.

  • No caching
  • No API for other scripts to use (You mentioned this was coming)
  • Session Locking

The reason these lack of features is bad is because your library has no way to customise it properly without editing the source code. You solely rely on users to interact with the instances created by the library to collect this data, and that’s all they are given access to.

You use modern features such as UpdateAsync, but you do not use them properly

image
image1076×80 7.92 KB

In this image I show your usage of UpdateAsync. You’re using it effectively the same as :SetAsync and do not even define the parameters for the current stored data to compare against.

You also don’t use the new DataStore metadata and versioning features which can be extremely helpful in rolling back data

4 Likes
#36

Why thank you for saying what the healthy human mind should of understood.

False. False. False.
You access it through ReplicatedStorage, the key i.d.r. being the Client’s UserId. Memory useage is minimal in exchange for features which metatables nor any other alternatives will grant you.

If you need to save data of anything else than a player, you’re usually wasting memory on useless things as per your logic.

Yes, thus I regarded those who did not understand as undereducated.

I do not think people would or should read code. I do take your critic though, documentation is a must.

In my perspective, a human mind should be able to understand what a format is. I believe you should of informed yourself what a table is.

The usage of pcall(), also known as protected call is to let the script run even if it errors. What you’re looking for is not pcall() rather retrying.

I don’t understand what’s being reinvented when I have not once used any other assets apart from Datastore itself.

Onto the good points.

I’m being paid a nice sum of money in a contract. After I finish it, I’ll be releasing this hobby of mine. It will include many things you all want.

I cannot say what will be there as it’s simply beautiful as a surprise, though I’d say it’ll be a free alternative to any other big Datastore paid services seen.

I thank you all for being part of this experiment.

#37

What i mean by don’t reinvent the wheel is that there is already good datastore modules out there such as profile service and datastore2. You module is not needed because of these good datastore modules so it feels like you are trying to reinvent solutions that are already implemented in those modules.

#38

they also can implement pcall it on the module, to attempt again use xpcall

local successed, data = xpcall(function()
    return Datastore:GetAsync(Key)
end, function() -- 1
    return DatastoreBackup:GetAsync(KeyBackup)
end)

if not successed then return self.Format end
return data

or

local successed, data = pcall(function()
    return Datastore:GetAsync(Key)
end)

if not successed then return self.Format end
return data
#39

You cannot consider this a suitable data store resource if you save data to instances in replicated storage. Attributes lack types which I may want to save in a table.

#40

Hi, I’ve been cooking up something that I cannot give previews of. You will be able to save a variety of types, perhaps all supported ones in the future. Unfortunately due to a lack of guidelines on how to make Plugins, I have not been able to develop as much as I wished to. I’ve got very little time for trial and error.

Here’s a little preview.

This was from weeks ago, it works different now and has undergone 6 version changes. I’ll only post this since I already shared it.