[erlang-questions] An Erlang 101 question

lloyd@REDACTED lloyd@REDACTED
Fri Jul 17 00:46:10 CEST 2015


Hi Garrett and Martin,

Yes, I'm using dets temporarily until I decide what database to use. All the dets-exposed functions are going through an api, e.g.:

contacts:get_contact(Email) ->
   contacts_api:get_contact(Email).

contacts_api:get_contact(Email) ->
   dets_contacts:get_contact(Email).

get_contact(Email) ->
   open_db(),
   Result = dets:lookup(?contacts, Email),
   close_db(),
   Result.

Sort of in the spirit of your suggestion to get something working then sweat the edge cases.

I'm not confident that the second level of indirection is necessary, but it reflects my current understanding of how to isolate record structures to one module only. I'm using Jesper's repr/2 code to access values.

Re: the idea of exposing db calls through a gen_server or e2 service, would this apply only to dbs such as dets that don't have transactions? Or is it good practice regardless of of the db back-end? 
   
As my last few posts may have hinted, with the help of Jesper and others I'm struggling to understand conventional Erlang practices that I, at least, have not found well documented. That's the problem of being a one-man-band. I can't call in my supervisor when I'm stuck. But folks have been extraordinarily generous with tips and information for which I'm profoundly grateful.

Martin--- thanks for your suggestion. I'll adopt it.

Thanks to all,

Lloyd
   

-----Original Message-----
From: "Garrett Smith" <g@REDACTED>
Sent: Thursday, July 16, 2015 5:37pm
To: "Lloyd Prentice" <lloyd@REDACTED>
Cc: "erlang-questions" <erlang-questions@REDACTED>
Subject: Re: [erlang-questions] An Erlang 101 question

Hey, I'm all for a direct solution, but this opening and closing of
the db for each read feels a little cavalier, even for me ;)

I would use a gen_server (e2 service) to maintain the open db,
flushing on each write to guard against data loss if the VM is
shutdown abruptly.

But to answer your question, a more canonical interface here would be
to return either {ok, Contact} or error (mapped from [Contact] or []
respectively) - or just return Contact and generate an exception if
the contact doesn't exists. The form depends on what you want this
function to do. See dict for an example of an interface that provide
both interfaces - and lets the user decide.

You're right though, exposing the dets interface here is wrong,
morally speaking.

On Thu, Jul 16, 2015 at 2:02 PM,  <lloyd@REDACTED> wrote:
> Hello,
>
> I have several functions that look like this:
>
> get_contact(Email) ->
>   open_db(),
>   Result = dets:lookup(?contacts, Email),
>   close_db(),
>   Result.
>
> The implication is that the function returns and empty list, [], if it fails to find a record, otherwise it returns a list containing the record.
>
> This makes it easy to distinguish the failure-to-return a record condition, but means that every function that depends up on get_contact/1 needs to do so and know what to do in that case. But that begins to feel like defensive programming.
>
> I can see several ways of dealing with this problem, but it occurs to me that there must be a conventional approach. What might be... what?
>
> Thanks,
>
> LRP
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions





More information about the erlang-questions mailing list