<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi!<br>
On 03/05/2013 05:21 PM, Diego Llarrull wrote:<br>
</div>
<blockquote cite="mid:51361B9C.6020402@tecso.coop" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div class="moz-cite-prefix">Ivan, Patrik:<br>
<br>
Thank you both for the swift replies! Both provided functions
that yield the desired results. The functions are: <br>
<br>
<tt><big><span style="font-size: 10pt;" lang="EN-US"> (I)
ets:match(table, {"Peter", [{"children", '$1'},'_'] }).
(Ivan's)</span></big></tt><tt><br>
</tt><tt><big> </big></tt><big><tt>(II)
ets:select(xxx,ets:fun2ms(fun({"Peter",[{"children",Data}|_]})
-> Data end)). (Patrick's)</tt></big><br>
<br>
(II) is effectively rendered to<br>
<br>
<big><tt>ets:select(xxx,[{{"Peter",{"children",'$1'}},[],['$1']}])</tt></big><br>
<br>
</div>
</blockquote>
Well, it's rendered to <br>
<tt><big>ets:select(xxx,</big></tt><tt>[{{"Peter",[{"children",'$1'}|'_']},[],['$1']}])</tt><br>
i.e. it matches an arbitrary long list as long as the first element
is a tuple of two elements having a first element of "children".<br>
<br>
ets:fun2ms happens at compile time (parse transform), so it's no
problem performance-wise.<br>
<br>
However, designing the table so that you have lists with certain
fields in known positions seems error prone, I think using
lists:keyfind on the result would be a better idea.<br>
<br>
If you worry about performance, the first thing you should do is to
replace the list strings with binaries (UTF-8 binaries preferably).
Matching a list means walking through the cons cells and is slightly
heavier than matching a binary. Binaries are also more compact. You
should also have tags like "children" as atoms, not lists. If the
number of possible fields is known in advance (which it would be if
you know the positions, or?) you could use tuples (or records)
instead of lists. With records you also are able to avoid the
lists:keyfind. It all depends on your application of course.<br>
<blockquote cite="mid:51361B9C.6020402@tecso.coop" type="cite">
<div class="moz-cite-prefix"> which is pretty similar to Ivan's
suggestion. My final question (and I so promise) is: it appears
to me that (I) performs better than (II) because of the lack of
need of a transformation function such as ets:fun2ms(). However,
I don't known for sure whether ets:match() outperforms
ets:select() or not. I'm about to run a series of tests on big
datasets to check this, but I imagine that there is already an
answer to this question. <br>
<br>
Once again, thank you very much. <br>
<br>
Diego<br>
</div>
</blockquote>
Cheers,<br>
/Patrik<br>
<blockquote cite="mid:51361B9C.6020402@tecso.coop" type="cite">
<div class="moz-cite-prefix"> <br>
<br>
El 05/03/13 11:34, Patrik Nyblom escribió:<br>
</div>
<blockquote cite="mid:5136028A.6010004@erlang.org" type="cite">
<div class="moz-cite-prefix">Hi!<br>
On 03/04/2013 08:58 PM, Diego Llarrull wrote:<br>
</div>
<blockquote cite="mid:5134FCDF.30607@tecso.coop" type="cite">
Hello everyone, <br>
<br>
I would like to insert in an ETS table a tuple with the
following type signature: <br>
<br>
<i><big><tt>{string(), [{string(), [string()]}]}</tt></big></i><br>
<br>
As an example: <br>
<i><br>
</i><i><big><tt>{"Peter", [{"children", ["Bob", "Paul"]},
{"father", ["Mike"]}]}</tt></big></i><i><br>
<br>
</i><br>
My question is the following: is it possible to solve, using
match specifications, nested queries like "Retrieve the name
of Peter's children" ?<br>
<br>
That is, a query where I would need to <br>
<br>
a) Fetch all ("the", since its a set) tuples of size 3 where
"Peter" is located in the first position (doable with MS)<br>
b) Let '$2' be the value in the second position of the tuple
fetched in a). Then, fetch the value corresponding to the key
"children" in '$2', if interpreted as a key-value list (i.e.
lists:keyfind() should work on '$2'). <br>
<br>
If I understood correctly, lists:keyfind can't be used inside
a match specification because they only allow the BIFs
described in <a moz-do-not-send="true"
href="http://www.erlang.org/doc/apps/erts/match_spec.html">http://www.erlang.org/doc/apps/erts/match_spec.html</a>.
My question is: is there any low-level mechanism to operate on
lists inside match specifications, or am I trying to push the
boundaries of match specifications?<br>
<br>
</blockquote>
Yes, you're trying to push the boundaries of match
specifications :)<br>
<br>
You'll have to do a lists:keysearch/keyfind on the results of
the ets:select (when you're back in proper Erlang code), only
constant time BIF's can be added to the ms language, so it's
unfortunately not even an option to add this particular
function... Without a huge rewrite that is... <br>
<br>
So...<br>
[lists:keyfind("children",1,P) || P <-
ets:select(xxx,ets:fun2ms(fun({"Peter",Data}) -> Data end))].<br>
would be the solution. Except of course if the list has a
particular order, or you instead use some record'ish data
structure, so that you can match directly:<br>
ets:select(xxx,ets:fun2ms(fun({"Peter",[{"children",Data}|_]})
-> Data end)).<br>
But looping over the list inside the ms is not possible.<br>
<blockquote cite="mid:5134FCDF.30607@tecso.coop" type="cite"> In
case anyone wonders "Why not use Query Lists Comprehensions?"
the answer is: "Because of performance issues: in our
platform, we need to dynamically build QLCs based on the
number of arguments that arrive, which forces us to build them
as strings and then use qlc:string_to_handle() which is SLOW".
<br>
<br>
Any help of insight will be greatly appreciated. Thank you
very much in advance. <br>
<br>
Diego Llarrull<br>
<br>
<br>
</blockquote>
Cheers,<br>
/Patrik<br>
<blockquote cite="mid:5134FCDF.30607@tecso.coop" type="cite"> <br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
erlang-questions mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
erlang-questions mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
erlang-questions mailing list
<a class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
</blockquote>
<br>
</body>
</html>