Immutability

 Immutability

How can data be immutable? Don’t facts change? They don’t, in fact, when you incorporate time in the data. For instance, when Obama became president, it didn’t mean that Bush was never president. So you just have "As Of" time column(s) in addition to the usual fact columns.

Reasons to make all types immutable:
    1) Do not change.
    2) Immutable objects are simpler to construct, test, and use
    3) Thread-safe. Most thread safety problems are due to writes on one thread and reads on another; immutable objects don't have writes.
    4) Avoid temporal coupling
    5) Usage is side-effect free (no defensive copies)
    6) always have failure atomicity
    7) much easier to cache
    8) prevent NULL references

    Immutable objects can be taken apart and re-used. For example, if you have an immutable binary tree then you can use its left and right subtrees as subtrees of a different tree without worrying about it. In a mutable structure you typically end up making copies of data to re-use it because you don't want changes to one logical object affecting another. This can save lots of time and memory.
     Suppose you have stack ABC and you want both stacks ABCX and ABCY in hand. If stack ABC is mutable then you have to make a copy then push X onto the original and the push Y onto the copy. If stack ABC is immutable then you can just copy the reference to ABC when you make your two new stacks. You don't have to copy the whole stack data structure. A structure which has this property is called "persistent".
     Suppose string were mutable (which they are not in C#) and you opened a file of a string filename.
       What if the hostile caller mutates filename after the security check and before the file is opened?
     Immutable strings allowing for optimizations via string interning

   Basically, there are 3 elements in every object: identity, state, and behavior. Identity is what distinguishes our document from other objects, state is what a document knows about itself (a.k.a. “encapsulated knowledge”), and behavior is what a document can do for us on request.
   The main difference between immutable and mutable objects is that an immutable one doesn’t have an identity and its state never changes.

Example of reason for mutable:
   The alien has fifty health points now but has ten after being hit by the laser beam.

Real-World Uses of Immutability:
    Accounting - The core idea is no one can change the original. Accounting systems do not want any changing of the original accounting transaction, but rather wants you to post your adjustment/correction/reversal as a separate event with the adjusted $ to bring it to the proper numbers.
    Most accounting systems also want as much data captured as possible automatically by the computer and not requested from the person. Auditing wants computer stamping of the transaction date, the person's identity of who is submitting the event, and location (such as terminal and store if corporation) so that you can track it back to someone. By having adjustments/corrections/reversals as a separate event, they expect the adjusting person, correction date, reversing location. Many systems want the reversals to have a list of the original transaction(s) so the auditor knows the intent of the correction.

SIMILAR EXAMPLE - Approvals, Status - could just be existence in table, Cryptographic Public Keys
IMMUTABLE EXAMPLE - Chain of Custody (Law Enforcement), Accounting/Auditing (Audit Log for free), Court Docket (expunge is special event),
   FINRA WORM compliance with financial data
PROGRAM EXAMPLE - GIT, Blockchain, Docker
LANGUAGE EXAMPLE - React, Redux

Disadvantages - Always doing summations to know the accurate number, because of always looking for adjustments/corrections/reversals. So slower since always looking for spans.


* Trie data structure *
  - Traditionally with tree if create new and change an element, it would take O(n) time
  - this only takes O(log n) time
  - dictionary
  - hash map

Location Independence:  Identity, Queries, Commands - Behavior
  Immutability Queries, Command - Partial Order, Identity - Uniqueness
  Locality - Auto Increment ID, Uniqueness constraint, Lock
  Local Independence = Low Latency, Autonomy, Temporal Decoupling

Historical Modeling is partially ordered : Audit Log, Synch Easy (Insert)
Event Sourcing - is full ordered
Examples:  Correspondence and Jinaga

Historical Modeling has FKs where "predecessor" is the linked parent table, "successor" is the linked parent table

Relational database we use FK to talk about cardinality (how many you got)
Historical Modeling we use FK to talk about causality (who first)


Historical Modeling on mutable properties instead are to have:
    new subtable with that CustomerName aspect with Name property.
    new subtable with that CustomerNamePredecessor aspect.

Historical Modeling on mutable properties instead are to have:
    new subtable with that CustomerAddress aspect with Name property.
    new subtable with that CustomerAddressPredecessor aspect.

This allows Identify and Resolve Conflicts and track Concurrency

Pessimistic Concurrency