Data-Alchemy - Declarative Datastore Library

Hello! I’m making this post to talk about a library I have written recently for Roblox datastores that allows you to define a datastore and its contents in a declarative fashion using custom classes. I wrote this library after starting work on a python database system for a project and finding that the way a popular python library for database interaction - sqlAlchemy - which this library is heavily inspired by, worked and really liked it.

The primary features of Data-Alchemy are:

  • Transactions
  • Declarative Data Structure
  • Promises
  • Attempts to provide more informative errors

I may add a few examples to the docs in the future, but as for now, the docs simply contain all relevant documentation for the library!

The source code can be found here:

and the documentation for it can be found here.

If you find any problems with it, please do report them on the library’s issues page!

7 Likes

This looks pretty good! Although, I wouldn’t call it transactions, it is more like batch-writes or a superficial implementation of a two-phase-commit protocol which is still pretty cool! You are making a bold assumption that the datastore wouldn’t fail when it is rolling back the data.

You should also check out the run-time type checking library t, it does what your datatypes tries to do but also more!

1 Like

I decided on calling them that because that’s exactly the thing they try to imitate to the best of their ability and I definitely am making a bold assumption there! Although, I could probably look into implementing something that can properly catch if the data failed to rollback and possibly retry it shortly later.

The only case I can see a rollback failing is due to a lack of datastore requests, the other case where it could fail would likely be due to datastores simply being down as I don’t think datastores have ever had an issue where their API calls don’t work 100% of the time but datastores still remained up and functional.

Wasn’t even aware this existed, looks neat but I think I’m gonna stick to writing my own datatypes, it does give me the idea to make some datatypes for all Roblox primitives and a way to allow multiple datatypes in a single column though!

True, though I was mainly speaking in the context of the possibility of it failing at the datastore’s level, and not the server’s level. I might implement something that can account for this case in a future update, however as of right now, I think the likelihood of a server crashing mid-transaction isn’t really that high to make it an immediate priority.

Well I might look into saving the snapshot information about the keys that were changed successfully to an extra key while the transaction is in process and simply checking if there was an in-progress snapshot by checking for the presence of that key. Right now I am working on implementing new datatypes.

1 Like

Updated for V2.0.0.

Changelog:

  • Added around 15 new DataTypes
  • Modified Enum, Integer, and Float DataTypes to be more powerful and flexible
  • Transactions failed due to the server crashing should now be reverted the next time the keys are interacted with
  • Fixed a few minor oversights/bugs in the code for Transactions

Transactions failing due to server crashing being reverted saying should is because I don’t believe there is a way to test for this with 100% accuracy, if there is however, I’d be happy to know about it so I can properly test if my implementation works!