You clearly don’t know how UpdateAsync works, you are clearly saving the data, as I showed you through the screenshot. When returning a value in the callback function of UpdateAsync, that value is saved.
That is my point, that’s isn’t useful session locking to the developer. There was no need to open source this module if you were being lazy to properly implement it, anyways, most of the developers don’t want to work with the “cancel” load method.
Don’t spread false information, ForceLoad doesn’t have the possibility to throttle since ProfileService specifically successive loads data every 10 seconds, ProfileService handles data corruption and error internally as well.
Not anymore, this has been fixed as the engineers at Roblox stated.
Data store errors aren’t rare, they occasionally happen and your entire point is incorrect, read up data store errors and limits to know more.
I clearly understand UpdateAsync given that I know that already. A set request is only made IF you don’t return “nil” on an UpdateAsync. And if the set request is not made for whatever reason, it won’t do a set request. UpdateAsync is just a get/set combo, with an extra queue system internally. (Not that important but yes).
That’s throttling. It’s just internal throttling.
Well if is, profile service should probably change that.
Even then, you were critizing my retry system, I’m trying to make datastore errors NOT happen. Like I said only write requests take 6 seconds to reload. And only so if they’re obviously done sucessfully. By waiting 6 seconds I’m doing useless throttling.
When I looked at profile service, it seemed to just consider data corruption when there is some partition of your data missing, like global updates, or metatags. And if your data isn’t a table. When “data corruption” happens, it will just reset the values to the template.
Another thing, I shouldn’t be sharing this, maybe I can, I think I saw it in the road map, but:
I’m comparing this to DataStore2, and they’re relatively the same, even going as far to listing what games currently use the system. I’m sort of confused on why this was made when a solution for this was already constructed? Both use berezaa’s method, and to be honest with you, making a different way to upload the datastore data is essentially the exact same as DS2.
Only thing I might be seeing different here is ProfileService but that’s just someone elses written API, and not an official ROBLOX thing AFAIK.
edit I know DS2 is not official, but it heavily relies on just Roblox Datastores alone
It has profile service included no? I still don’t get why this is any different
Oh wait… The thing isn’t built off profile service, it just uses ProfileService to sesson lock things? This just tells me it’s Datastore2, but with an extra feature they were probably already thinking of implementing.
I can see how many requests I made because I use the berezaa method, therefore I can list the versions. I have over 385 versions and never got one error. When I did it was in another game. And like I said, it doesn’t not throttle if it errored. Or if you return nil in an UpdateAsync call.
Gurl, profile service is a MODULE that does session locking, it’s not a separate thing. It just helps you mess with datastores without worrying about multi server editing.
DataStore+ can use the berezaa method behind the blinds. But mostly it will use a normal version and just keep backups. DataSave+ is just built on that and utilizes session locking.
Looks like I phrased that wrong, I’m not saying that it is a Datastore Saving thing, I was just stating that it’s sort of like Datastore2, only with an extra feature included. Unless the goal of this entire module is to not save data but pretty sure that’d defeat the purpose of the title.
I’m- what? That’s why there’s a retry system. I don’t know why you’re trying to bring that up, since I ready told you that it won’t throttle if it ends up not saving anything, either by error or choice.
I don’t think I mentioned reliability anywhere? This module IS reliable, I just don’t see why this type of module was made when we already got one that works just fine. That’s all.
That sounds perfectly reasonable! Personally if I were to make a module that everyone can use, I would just go to the page that they open sourced the module, and post my edit there. That’s just me though. Keep up the good work!
That’s not really possible friend. I remade the entire thing. this is written top-to-bottom, there’s no code from ANYONE else. Only some of other people’s ideas.
The point of my reply was to state that you could contribute to an already existing solution by recommending that they add the extra stuff that was found useful, so it can be put to good use, and you’d be credited for it. It would save you a lot more time than posting something that already is posted and used by tons.
Updated to 1.5.0, if you’re using it, please update your copy.
Update Log:
Session-locking improved, by detecting if there’s other servers are saving to the same key!
No longer using newproxy() on profile data and profile stores anymore, I was dumb I thought tables got cloned
Better saving by cloning the data before saving; Critical!
Optimization; yay!
Bug fixes
New profile function, :CopyData() will get you a deep COPY of the data stored. Changing anything on the copy won’t replicate to the profile data. It is used internally for saving data. You can set profile.Data now too.
