Are there any plans to separate ProfileService into multiple sub-modules for easier managament of stuff like Signal APIs? Why specifically did you go with packing everything into one module?
I’ll split it into separate modules when it reaches 10k lines
2 Likes
I’ve been using ProfileService for a while, I was thinking about creating a clan system using a combination of this and MessagingService. However, in order for that to work, wouldn’t a clan’s profile need to be accessed by multiple servers at the same time? (I’m new to doing things related to datastores and cross-server communication, so forgive me if I sound dumb at all) If so, is it possible to prevent a specific profile from being session locked?
Since UpdateAsync() is designed to save data in the order that each call is made, and nothing can really be duplicated in clans(so no reason for session locking?), it seems like having a clan saved as a profile + using MessagingService to apply changes made to the clan (new members, rank changes, etc) to other clan members online in different servers should work.
I was considering just programming my own separate global datastore for this as well. Which would be the better solution? If neither, how would you recommend going about this?
It doesn’t sound like you should use session-locking here, but for cross-server communication, you can use Global Updates if you were to use ProfileService.
Another thing, even though :UpdateAsync() supposedly ‘queues’ the calls, ProfileService has a UpdateAsync scheduler it self for every key to help on that even further. I also have some code that I made to help me do that, I can share it with you if you would like. (send me a dm in that case)
Hm, if you release it properly you should be fine, but if you’re looking for the stability of ProfileService and the auto-saving, you can have your load method as ‘Steal’, which loads the data pretty much right away and ignores the fact some data might be session locked.
Overall, if you need some data to be accessed by multiple servers at the same time, go for just using normal datastores.
You might be able to pull something off with :ViewProfileAsync() and using GlobalUpdates, but overall it seems like something you might wanna just keep in normal datastores.
1 Like
I really do want the stability of ProfileService, but if I use the ‘Steal’ load method, wouldn’t that still release data on other servers that are accessing that profile? In that case, wouldn’t I have to load the profile every time I’d want to make a change since any other server that’s loading that particular profile can cause it to release?
I’m also not very familiar with things relating to datastores. I can create my own system, but it wouldn’t turn out nearly as safe as ProfileService. I’d like to try and stick with using it if at all possible. Is there no way to prevent a specific profile from being session locked?
ProfileService is meant to resolve multi-server access until only one server keeps the session for a while. Every session stolen is around 15 seconds of the profile having its session lock transfered - at around 10 servers accessing the same profile key constantly you’ll completely lose write access to the profile and trying to patch it with manual session stealing will break ProfileService data security overall and will lead to unpredictable write access.
ProfileService profiles ARE NOT DESIGNED AND WILL NOT WORK for parallel multi-server writing. Period.
Individual DataStore keys ARE NOT DESIGNED for rapid parallel multi-server writing - you will run into throttling issues as your game grows.
2 Likes
How rapid does rapid parallel multi-server writing have to get to be dangerous? Does this apply to global datastores as well?
If this is the case then I don’t see how making a clan system using 1 key is even possible since it’s inevitable that a single key would be accessed by and written to by at least a few servers at the same time.
Hi again,
do you have a recommendation on how to update the leaderboard when a value in .Data changes?
I heard about metatables but I don’t know if that would work.
The only options I’ve thought of are a while wait(x) do loop or a server event in all scripts that can update data.
You need to create a signal for your data setter function or whatever setter you’ve got:
BindaleEvents for when you don’t need passed arguments to retain a live reference.
ScriptSignals for when you want to pass table arguments as references.
Afterwards you can connect all sorts of scripts, including your leaderboard updating code, to those signals.
I’d suspect most developers asking these questions would not be well informed of how ModuleScripts work and their ability to cache the return value and store things like ScriptSignal instances accessible to all scripts / ModuleScripts that require it - it helps a lot in creating event-based game scripts.
1 Like
I want to try making a global leaderboard for top player wins, can anybody point me in the right direction to how I could utilize ProfileService to do this?
It is not possible to use ProfileService that way:
Just make same thing you would do with normal DataStore.
How would I use it replacing DataStore’s default methods (:GetOrderedDataStore(), :GetSortedAsync(), :GetCurrentPage(), etc) ? Would I have to sort the data myself, and if so would it be more beneficial to save the same data separately in a DataStore to take advantage of these methods?
Somebody had suggested using Global Updates, is this not possible?
I just don’t know why would you want saving OrderedDataStore with ProfileService :D.
How would I use ProfileService to do the same thing I would with normal DataStore?
1 Like
[05/04/2021] Profile.MetaTags now retains the same table reference after every auto-save
Before this fix, trying to store a reference to Profile.MetaTags to a variable would not work as expected since whenever ProfileService updated MetaTags it set Profile.MetaTags to a new table reference every time.
You may update the module through github or the Roblox library .
4 Likes
Just swapped from DS2 to ProfileService, heavily recommend ProfileService if you’re making an RPG game with multiple instances. Working flawlessly for me!
2 Likes
I assume that ProfileService will be updated immediately when DataStore v1.1 releases?:
https://devforum.roblox.com/t/sunsetting-legacy-data-persistence-systems/1206245
Because if I correctly remember, ProfileService only uses UpdateAsync(), and the new DataStore v1.1 (currently being tested and is private) appears to focus on updating. I highly doubt it will affect anything however.
1 Like