Session locking cannot (currently) be disabled, and for good reason; it seems that lapis is designed with session locking in mind. Although, it would be great if it wasn't.
Use case
I'm working on a game that has a system similar to "clans" or "guilds". These have mutable data elements that can be changed across multiple servers, eg;
Members joining and leaving the guild
Guild details updating
Some other game specific features
As these elements can be mutated across multiple servers- they have to be sync'd every N minutes, and updates have to be in the form of UpdateAsync with a provided callback that handles reconciliation between guilds. This reconciliation would be a great place to take advantage of lapis' Document abstraction.
Closing thoughts
This might be outside the scope of lapis' design philosophy, but I thought I'd suggest it just in case it's something you're interested in. I'd really like to take advantage of lapis in my current project- instead of needing to write my own wrapper around data stores; although, this may also just be a space that needs filling by a separate project/service (multi-server data store access).
Overview
Session locking cannot (currently) be disabled, and for good reason; it seems that lapis is designed with session locking in mind. Although, it would be great if it wasn't.
Use case
I'm working on a game that has a system similar to "clans" or "guilds". These have mutable data elements that can be changed across multiple servers, eg;
As these elements can be mutated across multiple servers- they have to be sync'd every N minutes, and updates have to be in the form of
UpdateAsyncwith a provided callback that handles reconciliation between guilds. This reconciliation would be a great place to take advantage of lapis'Documentabstraction.Closing thoughts
This might be outside the scope of lapis' design philosophy, but I thought I'd suggest it just in case it's something you're interested in. I'd really like to take advantage of lapis in my current project- instead of needing to write my own wrapper around data stores; although, this may also just be a space that needs filling by a separate project/service (multi-server data store access).