STM / TRef API

[sidnt]

class TRef[A] extends AnyRef
// A variable that can be modified as part of a transactional effect. 
// Self Type TRef[A]
// Value Members

    final val get: STM[Nothing, A]
    // Retrieves the value of the TRef.

    final def modify[B](f: (A) => (B, A)): STM[Nothing, B]
    // Updates the value of the variable, returning a function of the specified value.

    final def modifySome[B](default: B)(f: PartialFunction[A, (B, A)]): STM[Nothing, B]
    // Updates some values of the variable, returning a function of the specified value or the default.

    final def set(newValue: A): STM[Nothing, Unit]
    // Sets the value of the TRef.

    final def toString(): String

    final def update(f: (A) => A): STM[Nothing, A]
    // Updates the value of the variable.

    final def updateSome(f: PartialFunction[A, A]): STM[Nothing, A]
    // Updates some values of the variable but leaves others alone.

on the companion object

object TRef

final def make[A](a: => A): STM[Nothing, TRef[A]]
//Makes a new TRef that is initialized to the specified value.

final def makeCommit[A](a: => A): UIO[TRef[A]]
//A convenience method that makes a TRef and immediately commits the transaction to extract the value out.

[sidnt]

first of all, we need transactional references. in practice, we'll use a number of transactional references together in an STM transaction, so that we can update them transactionally.

what if we wanted to provision an inmemory acid database for an app? it will eventually be a key value store. eventually, when it comes to data crossing the database boundary, we will be crudding key-value pairs.

given that the application is stateless, in practice, what is an application's data? how big is it? how is it distributed? what does it look like? coursera.org is my handle to that application, and what is coursera app's data like?

one thing that's common across all these strategies/variations in data, is that they all come with a map, or they are useless, if we can't reference them. there's always a map, which helps us get to the data.

the only nvm available to one single host machine, is its disk based storage, ie, persistent store, or more appropriately, nvm - nonvolatile memory, henceforth. past that, there's the RAM (which is volatile and loses data upon power off)

data for one app live on one node,

we can't reuse def/val/var reference names in our program. so these names act like keys to the values they reference.

[sidnt]

in memory stm database like thing, is already exemplified in the diode way of doing things. first of all, there, is a singular tree. and when you dispatch actions, they contain all the information needed to mutate the tree, and several transactions dispatched, will be execute one by one, the changes requested will be made visible transactionally in the state tree.

also, in diode, you have to define the actions and their handlers. handler is just a pure function from (oldstate, action) => newstate. handler can send off effects as well, upon receipt of an action, eg, a post call to a route. and not only that, from the results of that effect, create and dispatch another action.

because, if not appropriately managed,