[erlang-questions] Desing of MVC models

[Ludovic Demblans]

Thank you all for your answers.

Dmitry i dont understand what you mean by "HA" .. I'm not really into
ditributed Erlang at the moment but i should definitely make somes
tests. For now, if my lonely node crashes, as data is saved often to
disc (e.g. in Postgres), it should be fresh. I just hope thant the
entire server doesn't burn...

Loïc, you said :

"""You most likely don't need to store all of this in a database."""

Actually, this is a browser game server, the kind of you refresh a few
times in a day to update things (buildings, productions, skills, ...),
all the data must be saved often. And as people aren't connected
continuously, i don't want all my data living in RAM all of the time.
(BTW i should upgrade my hosting, but for now i am quite limited on
RAM)

Jesper said that "you can quickly communicate in the same memory space
between processes, so you don't need a mediating DB layer". Yup, the
database is only there to be a persistance layer, not to allow
"things" to communicate. The models are there to bring the data to the
application, then to store this data if changed.

My code example was bad. When you update a record in my models, they
are not saved each time, you must call a 'store' function on the
model. Thats why i did the 'proc' function : first you load the data
 from the database, then the controller can .. control things and
finally the record is updated and saved once.

     ... Controller calculations ...
       DamgeDone = calculate_damage_done(...)
       Conn = nemo:get_connection(testdba),
       M = nemo:load(ship,<ship_id>,Conn),
       Proc = [{get,health_points},
               fun(HP,Ship) ->
                   Ship#ship{health_points = HP- DamgeDone}
               end,
               {store}], %% <--- triggers the database update
       NewHealthPoints = m:proc(M,Proc)

Plus, i wanted to build a model which could be used for any data in a
more common web application : pages, articles, slidshows, todos, etc.
Something more general as BossDB does.

With the use of 'methods' in my models, written in the relevant 'type
module' like ship.erl, i'm not so far from a regular gen_server. THe
truth is i was fed up writing gen_servers again and again to do theese
kind of things. But in the end it's barely the same thing.

But i will follow your advice, i will use my code to build prototypes
of servers and when things are kind of stable, turn theese models in
regular gen_server instances. This should speed up code execution.

And yes, my application is standalone, it just setup cowboy or yaws to
be accessible through the web.


Thanks you all again, this helps

Le Fri, 13 Sep 2013 13:01:55 +0200, Dmitry Kolesnikov  
<dmkolesnikov@REDACTED> a écrit:

> Hello,
>
> On Sep 13, 2013, at 12:59 PM, Jesper Louis Andersen  
> <jesper.louis.andersen@REDACTED> wrote:
>
>> In Erlang, you have options. Safety is had due to isolation, so you  
>> don't have to push data onto stable storage as often. And you can  
>> quickly communicate in the same memory space between processes, so you  
>> don't need a mediating DB layer.
>
> This is precisely true… However, if we are talking about MMO gaming I  
> see one potential issue which requires some clarification. Often, the  
> data availability is important. Player would not forgive you if they  
> "almost" win the battle but they status rolled back due to server crash  
> or other failure that impact your "live" data.
>
> What would be possibilities to achive desired HA for transient data in  
> Erlang and recover node failures. HA is required for millions of  
> processes (e.g. process per user, process per ship, etc).
>
>  * Keep copies of same data on two distinct nodes. Basically you spawn  
> two "ship" management processes on node A and B. However, you as app  
> developer is responsible to implement state conflict resolution,  
> rollback, recovery, etc.
>
>  * Use Mnesia, Riak as HA transient storage but this does not differ for  
> my taste as any other mediating DB layer at some respect.
> * Use external DB layer but make asynchronous checkpoint of process  
> status
>
> Did I miss something?
>
> Best Regards,
> Dmitry


-- 
Utilisant le logiciel de courrier révolutionnaire d'Opera :  
http://www.opera.com/mail/