Datastore library that is not player data centric?

[detroitboy_0616]

i looked at Datastore2 and ProfileService but they appear to focus on saving the current player data.
I am creating a game where ppl can submit their own text stories and let other ppl search them by keyword, etc. so the key is not going to be at player level but at story level. there will be feedback/rating system as well.

I could write a module wrapping vanilla DataStore that handles failures/retry/concurrent write, etc but before i do that, is there a library that simplify them?

Also, what is the best library for writing unit test? I obviously cannot do this talking to the actual DataStore because everytime test run, there will be garbage data from previous runs and affect test result. Is MockDataStoreService (GitHub - buildthomas/MockDataStoreService: Emulation of Roblox's DataStoreService for seamless offline development & testing) the best we have?

Thanks

[arbitiu (arbi)]

I wouldn’t really call ProfileService user centric, however, I don’t think session locking would be something that the game concept you describe needs.

I haven’t really heard of a library that would help you in this case, and if there is one it’s probably not battle tested enough.

You could quite easily implement handling of failures and retries with the Promise library, and considering you plan on using MockDataStore, it’s probably whats best for you as it would allow you to swap between the mock and real datastore quickly

[detroitboy_0616]

thanks for reply. i don’t see what ProfileService would give me that DataStore doesn’t provide.; my understanding is, its biggest value is session lock and auto saving.

i am trying to decide if it is more straight forward for me to just roll my own.
i feel like other larger dev teams must have similar issue.

[Dev_Peashie]

I’m not sure if I can consider the DatastoreService as a “player centric” thing.
About ProfileService and many other modules out there that are only tools to make life easier handling the DatastoreService, I don’t know any cause I never used them.

Obviously I need more specific data about your goal, in order to suggest what approach I would do. So I can only base my reply on what you said:

@detroitboy_0616

a game where ppl can submit their own text stories and let other ppl search them by keyword, etc. so the key is not going to be at player level but at story level. there will be feedback/rating system as well.

If you have a “StoriesDS”, you could save every story created (be sure to keep track of the 4mb limits per entry and limits so you can create new ones are needed)

The Keys of that StoriesDS would be the “keyword” (perhaps the title condensed) and the content a table with the “story”, and keys for the author, possibly the rate, feedback, creation date, etc, whatever you find helpful.

Then a second Datastore, lets call it “bibliographyDS”, so. Whenever a player submits a story to be saved on “StoriesDS” you ask the player to select a “keyword” to save that story under that entry, and at the same time you save only the keyword into “bibliographyDS” but, dont use the keyword as the Key, use a specif you decided for the Key as “All_Keywords”, and inside that Key you save all the Keywords from the Stories that the players are creating. (careful with DS limits again, and you need a queue system in order to avoid max time limits to rewrite on the DS)

So, bibliographyDS, contains just a list of all keywords that exist in your library, with that you can create a GUI to show all the stories that exist to players and save many other values you consider as needed (perhaps the rate, etc should be in here is you save nested tables)

Now, players can browse or search along the data in bibliographyDS and select one, that keyword is the same one that StoriesDS uses as Keys, so you can ask StoriesDS to give back the whole text/story along with important data that the nested keys contains.

Additionally, you could create a third DSS that is player based (the normal way, using the user ID number as Keys) to save the Keywords that the player submitted, in that way, each player can have a GUI that shows the Stories/Keywords they created, and load them (by calling the StoriesDS) and get the content in order to edit or whatever you prefer.

So, handling multi DS’s a dedicated DS for stories with Keyword Keys, a dedicated DS for bibliography with static Key holding all Keys in game, and a player based DS to give player’s features. The basic idea you explained can be achieved

[detroitboy_0616]

thanks. yeah i figured out the schema part, i was hoping someone has some generic data access layer figured out so i don’t have to write those generic parts (retry, etc). I guess i will have to write one myself.

re: keyword and stuff, lack of multi-item transaction support makes it slightly difficult. i am not dealing with $ so i should be able to tolerate some errors, but still it does make things little more complicated.