<div dir="ltr"><div>I'm in a project that's stuck back on a very old version of Erlang.<br></div><div>We don't have the capability of using maps so we use records as our "Erlang" model. I'm not sure if you're stuck using records. If you can use maps, I think that fits best. If you HAVE to use records though, We've had good luck utilizing jiffy along with an additional translation layer in our code. Your translation layer can be responsible for handling the transformation to and from EJSON. </div><div><br></div><div>The key component is using `record_info(fields, _)` which will allow you to get your record keys at run-time. I've often done this with a macro:</div><div><br></div><div>```erlang</div><div>-record(my_record, {id}).</div><div>-define(RECORD_KEYS, record_info(fields, my_record))</div><div>%% ?RECORD_KEYS = [id].</div><div>```</div><div><br></div><div>After you've got your keys, you should be able to do all sorts of shenanigans to make the mapping for your intermediary layer.</div><div><br></div><div>Fair warning though, the intermediary layer starts to get a little weird if you use records that contain other records or if you want to make it generic. If you decide to go that route and have other questions feel free to hit me up off list.<br></div><div><br></div><div>First mailing list reply btw, if i did something wrong/incorrect, just email me off list about it and I'll fix it for next time.</div><div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 15, 2015 at 1:28 PM, Kannan <span dir="ltr"><<a href="mailto:vasdeveloper@gmail.com" target="_blank">vasdeveloper@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I was out of Erlang programing for the last five years, I think maps has been introduced during that time. I was not aware of it earlier. Just went through the documentation, and yes it is the best format to match JSONs.<div><br></div><div>The syntax is quite complicated though. Using two characters to map key and value, assignment, update, access and matching have different K-V separator symbols etc. However, as a declaration free K-V grouping structure, it is the best option.</div><div><br></div><div>Regards,</div><div>Theepan</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 15, 2015 at 11:33 PM, Garry Hodgson <span dir="ltr"><<a href="mailto:garry@research.att.com" target="_blank">garry@research.att.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>I prefer mapping json objects to erlang
      maps, lists to lists, and strings to binaries. i use a wrapper
      around mochijson to do that.<div><div><br>
      <br>
      On 7/15/15 2:00 PM, Kannan wrote:<br>
    </div></div></div>
    <blockquote type="cite"><div><div>
      <div dir="ltr">Is any of them supporting Erlang 'record' as their
        base for encoding/decoding. I see many of them are doing it with
        just list of tuples of binaries.Erlang records best match the
        structure of JSON format.
        <div><br>
        </div>
        <div>JSON</div>
        <div>----------</div>
        <div>{"name": "Theepan",</div>
        <div>  "work": "Coding",</div>
        <div>  "salary": "0"</div>
        <div>}</div>
        <div><br>
        </div>
        <div>Matching Erlang record</div>
        <div>-----------------------------------</div>
        <div>-record( json_record,</div>
        <div>{</div>
        <div>  'name' = "Theepan",</div>
        <div>  'work' = "Coding",</div>
        <div>  'salary' = "0"</div>
        <div>}</div>
        <div>}<br>
          <div><br>
          </div>
          <div>Thanks,</div>
          <div>Theepan</div>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Wed, Jul 15, 2015 at 2:33 PM, Jesper
          Louis Andersen <span dir="ltr"><<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@gmail.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div dir="ltr"><span>
                <div class="gmail_extra"><br>
                  <div class="gmail_quote">On Tue, Jul 14, 2015 at 10:06
                    PM, Kannan <span dir="ltr"><<a href="mailto:vasdeveloper@gmail.com" target="_blank">vasdeveloper@gmail.com</a>></span>
                    wrote:<br>
                    <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                      <div>I come across many JSON libraries. Once from
                        MochiWeb, Other one from Yaws. Third one from
                        CouchDB. And some others through Googling.</div>
                    </blockquote>
                  </div>
                  <br>
                </div>
              </span>
              <div class="gmail_extra">There are two very popular JSON
                parsers in Erlang: jsx and jiffy.<br>
                <br>
              </div>
              <div class="gmail_extra">jsx is written in plain Erlang.
                It is fast, correct and since it is written in Erlang,
                it will also automatically yield for other processes in
                the system.<br>
                <br>
              </div>
              <div class="gmail_extra">jiffy is written as a C NIF. It
                is about 10 times faster than jsx, but the caveat is
                everything that has to do with C NIFs: blocking a
                scheduler, C code having errors, security
                considerations, etc.<br>
                <br>
              </div>
              <div class="gmail_extra">I tend to run with `jsx` in my
                projects, and then I switch away from JSON when it gets
                to slow. JSON is a bad format that should never have
                existed in the first place. We are stuck with it because
                it's historic alternative, XML, was far worse in every
                aspect.<span><font color="#888888"><br>
                  </font></span></div>
              <span><font color="#888888">
                  <div class="gmail_extra"><br clear="all">
                    <br>
                    -- <br>
                    <div>J.</div>
                  </div>
                </font></span></div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><span><pre>_______________________________________________
erlang-questions mailing list
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
    </span></blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div></div>