Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You can effectively use immutable Entities in Scala and avoid the horror of mutable fields and all the bugs that derives from mutable state. Using Immutable entities help you with concurrency, doesn't make things worse. Your previous mutable state will become a set of transformation which will create a new reference at each change. </p> <p>At a certain level of your application, however, you will need to have a mutable state, or your application would be useless. The idea is to push it as up as you can in your program logic. Let's take an example of a Bank Account, which can change because of interest rate and ATM withdrawal or deposit. </p> <p>You have two valid approaches:</p> <ul> <li><p>You expose methods that can modify an internal property and you manage concurrency on those methods (very few, in fact)</p></li> <li><p>You make all the class immutable and you surround it with a "manager" that can change the account.</p></li> </ul> <p>Since the first is pretty straightforward, I will detail the first.</p> <pre><code>case class BankAccount(val balance:Double, val code:Int) class BankAccountRef(private var bankAccount:BankAccount){ def withdraw(withdrawal) = { bankAccount = bankAccount.copy(balance = bankAccount.balance - withdrawal) bankAccount.balance } } </code></pre> <p>This is nice, but gosh, you are still stuck with managing concurrency. Well, Scala offers you a solution for that. The problem here is that if you share your reference to BankAccountRef to your Background job, then you will have to synchronize the call. The problem is that you are doing concurrency in a suboptimal way.</p> <p><strong>The optimal way of doing concurrency: message passing</strong></p> <p>What if on the other side, the different jobs cannot invoke methods directly on the BankAccount or a BankAccountRef, but just notify them that some operations needs to be performed? Well, then you have an Actor, the favourite way of doing concurrency in Scala.</p> <pre><code>class BankAccountActor(private var bankAccount:BankAccount) extends Actor { def receive { case BalanceRequest =&gt; sender ! Balance(bankAccount.balance) case Withdraw(amount) =&gt; { this.bankAccount = bankAccount.copy(balance = bankAccount.balance - amount) } case Deposit(amount) =&gt; { this.bankAccount = bankAccount.copy(balance = bankAccount.balance + amount) } } } </code></pre> <p>This solution is extensively described in Akka documentation: <a href="http://doc.akka.io/docs/akka/2.1.0/scala/actors.html" rel="noreferrer">http://doc.akka.io/docs/akka/2.1.0/scala/actors.html</a> . The idea is that you communicate with an Actor by sending messages to its mailbox, and those messages are processed in order of receival. As such, you will never have concurrency flaws if using this model.</p>
    singulars
    1. This table or related slice is empty.
    1. POFunctional Programming + Domain-Driven Design
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USEdmondo1984
    1. USEdmondo1984
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POFunctional Programming + Domain-Driven Design
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COBut aren't there risks to have a set of transformation currently in memory? Let's imagine that different threads for several background job tasks maintain different versions of the same entity. This would lead to inconsistency, wouldn't it?
      singulars
      1. PO
      1. USMik378
    2. COI understand where you are coming from. Background jobs maintaining state can be a source of problems. I still wonder which use case is a valid one for maintaining a shared state among independent background jobs
      singulars
      1. PO
      1. USEdmondo1984
    3. COUse-case? Bank accounts. Background jobs could be reporting, ATM-handlers, interest-rate-calcualators...
      singulars
      1. PO
      1. USThe Archetypal Paul
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload