triceps
view release on metacpan - search on metacpan
view release on metacpan or search on metacpan
doc/html/guide.html view on Meta::CPAN
following updates.
</p><pre class="programlisting"><span class="bold"><strong>c1|d,symbol,OP_INSERT,DEF,Defense Corp,2.0</strong></span>
c1|d,symbol,OP_INSERT,DEF,Defense Corp,2</pre><p>
Send some more data, and it comes back only once, even though the
subscription was done twice: once in <span class="quote">“<span class="quote">subscribe</span>”</span> and once in <span class="quote">“<span class="quote">dumpsub</span>”</span>.
The repeated subscription requests simply get consumed into one
subscription.
</p><pre class="programlisting"><span class="bold"><strong>c1|d,window,OP_INSERT,1,ABC,101,10</strong></span></pre><p>
This sends a row to the other table but nothing comes back because
there is no subscription to that table.
</p><pre class="programlisting"><span class="bold"><strong>c1|dumpsub,ds4,window</strong></span>
c1|startdump,ds4,window
c1|d,window,OP_INSERT,1,ABC,101,10
c1|dumpsub,ds4,window
<span class="bold"><strong>c1|d,window,OP_INSERT,2,ABC,102,12</strong></span>
c1|d,window,OP_INSERT,2,ABC,102,12</pre><p>
This demonstrates the pure dump-and-subscribe without any interventions.
</p><pre class="programlisting"><span class="bold"><strong>c1|shutdown</strong></span>
c1|shutdown,,,,
c1|__EOF__</pre><p>
And the shutdown command works the same as in the chat server, draning
and then shutting down the whole server.
</p><p>
Now on to the queries.
</p><pre class="programlisting"><span class="bold"><strong>connect c1</strong></span>
c1|ready
<span class="bold"><strong>c1|d,symbol,OP_INSERT,ABC,ABC Corp,1.0</strong></span></pre><p>
Starts a client connection and sends some data.
</p><pre class="programlisting"><span class="bold"><strong>c1|querysub,q1,query1,{read table symbol}{print tokenized 0}</strong></span>
c1|d,query1,OP_INSERT,ABC,ABC Corp,1
c1|querysub,q1,query1</pre><p>
The <span class="quote">“<span class="quote">querysub</span>”</span> command does the <span class="quote">“<span class="quote">query-and-subscribe</span>”</span>: reads the
initial state of the table, processed through the query, and then
subscribes to any future updates. The single-threaded variety of TQL
doesn't do this, it does just the one-time queries. The multithreaded
TQL could potentially do the one-time queries, and also just the subscribes
without the initial state, but so far I've been cutting corners
and the only thing that's actually available is the combination
of two, the <span class="quote">“<span class="quote">querysub</span>”</span>.
</p><p>
Similarly to the other commands, <span class="quote">“<span class="quote">q1</span>”</span> is the command identifier. The next
field <span class="quote">“<span class="quote">query1</span>”</span> is the name for the query, it's the name that will be
shown for the data lines coming out of the query. And then goes the
query in the brace-quoted format, same as in the single-threaded TQL (and
there is no further splitting by commas, so the commas can be used
freely in the query).
</p><p>
The identifier and the name of the query sound kind of redundant. But
the client may generate them in different ways and need both. The name
has the more symbolic character. The identifier can be generated as a
sequence of numbers, so that the client can keep track of its progress
more easily. And the error reports include the identifier but not the
query name in them.
</p><p>
For the query, there is no special line coming out before the initial
dump. Supposedly, there would not be more than one query in flight with
the same name, so they could be easily told apart based on the name in
the data lines. There is also an underlying consideration that when the
query involves a join, in the future the initial dump might be
happening in multiple chunks, requiring to either surround every chunk
with the start-end lines or just let them go without the extra
notifications, as they are now.
</p><p>
And the initial dump ends as usual with getting the echo of the command
(without the query part) back.
</p><p>
This particular query is very simple and equivalent to a <span class="quote">“<span class="quote">dumpsub</span>”</span>.
</p><pre class="programlisting"><span class="bold"><strong>c1|d,symbol,OP_INSERT,DEF,Defense Corp,2.0</strong></span>
c1|d,query1,OP_INSERT,DEF,Defense Corp,2</pre><p>
Send more data and it will come out of the query.
</p><pre class="programlisting"><span class="bold"><strong>c1|querysub,q2,query2,{read table symbol}{where istrue {$%symbol =~
/^A/}}{project fields {symbol eps}}</strong></span>
c1|t,query2,query2 OP_INSERT symbol="ABC" eps="1"
c1|querysub,q2,query2</pre><p>
This query is more complicated, doing a selection (the <span class="quote">“<span class="quote">where</span>”</span> query
command) and projection. It also prints the results in the tokenized
format (the <span class="quote">“<span class="quote">print</span>”</span> command gets added automatically if it wasn't used
explicitly, and the default options for it enable the tokenized
format).
</p><p>
The tokenized lines come out with the command <span class="quote">“<span class="quote">t</span>”</span>, query name and then
the contents of the row. The query name happens to be sent twice, and
I'm not sure yet if it's a feature or a bug.
</p><pre class="programlisting"><span class="bold"><strong>c1|d,symbol,OP_INSERT,AAA,Absolute Auto Analytics Inc,3.0</strong></span>
c1|d,query1,OP_INSERT,AAA,Absolute Auto Analytics Inc,3
c1|t,query2,query2 OP_INSERT symbol="AAA" eps="3"
<span class="bold"><strong>c1|d,symbol,OP_DELETE,DEF,Defense Corp,2.0</strong></span>
c1|d,query1,OP_DELETE,DEF,Defense Corp,2</pre><p>
More examples of the data sent, getting processed by both queries. In
the second case the <span class="quote">“<span class="quote">where</span>”</span> filters out the row from query2, so only
query1 produces the result.
</p><pre class="programlisting"><span class="bold"><strong>c1|shutdown</strong></span>
c1|shutdown,,,,
c1|__EOF__</pre><p>
And the shutdown as usual.
</p><p>
Now the <span class="emphasis"><em>piece de resistance</em></span>: queries with joins.
</p><pre class="programlisting"><span class="bold"><strong>connect c1</strong></span>
c1|ready
<span class="bold"><strong>c1|d,symbol,OP_INSERT,ABC,ABC Corp,2.0</strong></span>
<span class="bold"><strong>c1|d,symbol,OP_INSERT,DEF,Defense Corp,2.0</strong></span>
<span class="bold"><strong>c1|d,symbol,OP_INSERT,AAA,Absolute Auto Analytics Inc,3.0</strong></span>
<span class="bold"><strong>c1|d,window,OP_INSERT,1,AAA,12,100</strong></span></pre><p>
Connect and send some starting data.
</p><pre class="programlisting"><span class="bold"><strong>c1|querysub,q1,query1,{read table window}{join table symbol byLeft
{symbol} type left}</strong></span>
c1|t,query1,query1 OP_INSERT id="1" symbol="AAA" price="12" size="100"
name="Absolute Auto Analytics Inc" eps="3"
c1|querysub,q1,query1</pre><p>
A left join of the tables <span class="quote">“<span class="quote">window</span>”</span> and <span class="quote">“<span class="quote">symbol</span>”</span>, by the field <span class="quote">“<span class="quote">symbol<...
as join condition.
</p><p>
The TQL joins, even in the multithreaded mode, are still implemented
internally as LookupJoin, driven only by the main flow of the query. So
the changes to the joined dimension tables will not update the query
results, and will be visible only when a change on the main flow picks
them up, potentially creating inconsistencies in the output. This is
wrong, but fixing it presents complexities that I've left alone until
some later time.
</p><pre class="programlisting"><span class="bold"><strong>c1|d,window,OP_INSERT,2,ABC,13,100</strong></span>
c1|t,query1,query1 OP_INSERT id="2" symbol="ABC" price="13" size="100"
view release on metacpan - search on metacpan
( run in 0.638 second using v1.00-cache-2.02-grep-82fe00e-cpan-48ebf85a1963 )