
<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<title></title>

</head>

<body>

<div name="messageBodySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;">There's no unbounded atom creation. Since you have the GraphQL schema, you know upfront which atoms

<div>are allowed and which aren't. You only convert those that are allowed.</div>

</div>

<div name="messageSignatureSection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;"><br />

Michał.</div>

<div name="messageReplySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;"><br />

On 25 May 2017, 15:19 +0200, duncan@sfractal.com, wrote:<br />

<blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #1abc9c;">I thought unbounded atom creation was to be avoided. If you switch to<br />

atoms, how do prevent the original concern "using atoms is just bound to<br />

fill Erlang's atom table", especially if it is driven by user data?<br />

I could foresee a hacker crashing the system by just varying lots of<br />

inputs. If the failure is limited by your architecture to just<br />

processes of that user then you can just 'let it fail'. But if filling<br />

the atom table is a wider crash than just a single user-specific server<br />

process, then it's worth thinking about avoiding.<br />

<br />

Duncan Sparrell<br />

sFractal Consulting LLC<br />

iPhone, iTypo, iApologize<br />

<br />

<br />

<br />

-------- Original Message --------<br />

Subject: Re: [erlang-questions] [ANN] GraphQL Erlang 0.8.0<br />

From: Jesper Louis Andersen <jesper.louis.andersen@gmail.com<br />

Date: Wed, May 24, 2017 10:57 am<br />

To: Son Tran-Nguyen <son@sntran.com<br />

Cc: "Erlang (E-mail)" <erlang-questions@erlang.org<br />

<br />

On Wed, May 24, 2017 at 4:31 PM Son Tran-Nguyen <son@sntran.com> wrote:<br />

<br />

If any, please consider letting the develop to choose whether they want<br />

to convert the binary to atom. If the library switch itself to using<br />

atoms, then the developer cannot really do anything about it.<br />

<br />

<br />

<br />

<br />

<br />

If we make the switch, I'm pretty sure the developers won't be given a<br />

choice. The complexity of managing this will essentially mean every<br />

module in the system needs lots of small fixups. The cost/benefit<br />

analysis doesn't pan out.<br />

<br />

<br />

The impedance mismatch is when you have a field as an atom, 'created'<br />

for instance. But your object stores it as <<"created">> in a map or<br />

proplist. In this case, the code would change from<br />

<br />

<br />

execute(_, Obj, Field, _) -> {ok, maps:get(Field, Obj, null)}<br />

<br />

<br />

to<br />

<br />

<br />

execute(_, Obj, Field, _) -> {ok, maps:get(atom_to_binary(Field, utf8),<br />

Obj, null)}<br />

<br />

<br />

which I don't think is a problem in the long run. It would help if the<br />

data is a #record{} type on the other hand.<br />

<br />

<br />

<br />

_______________________________________________<br />

erlang-questions mailing list<br />

erlang-questions@erlang.org<br />

http://erlang.org/mailman/listinfo/erlang-questions<br />

_______________________________________________<br />

erlang-questions mailing list<br />

erlang-questions@erlang.org<br />

http://erlang.org/mailman/listinfo/erlang-questions<br /></blockquote>

</div>

</body>

</html>