This program is executed in a weird manner in the push-based runtime:
class PushPredicates
include Bud
state do
table :t_in
table :t_out1, [:a, :b, :c]
end
bootstrap{t_in <= [[1,1],[2,2]]}
bloom do
t_out1 <= (t_in*t_in).lefts do |t1|
['inc', 'inc', t1.key] if t_in.pro{|t| puts "t = #{t}"; [t.key]}.include? 1
end
end
end
def test_predicates
p = PushPredicates.new
p.tick
assert_equal([['inc', 'inc', 1], ['inc', 'inc', 2]], p.t_out1.to_a)
end
Prior to a recent checkin, calling pro on t_in in the body of the join would result in creating additional wirings at runtime, which definitely doesn't seem sound. However, now that we've changed BudCollection#pro to call @storage.pro when called outside wiring, this program doesn't produce the expected results (t_out1 is empty).
We should consider whether to support such programs, and if so, what the best approach is.
This program is executed in a weird manner in the push-based runtime:
Prior to a recent checkin, calling
pro
ont_in
in the body of the join would result in creating additional wirings at runtime, which definitely doesn't seem sound. However, now that we've changed BudCollection#pro to call @storage.pro when called outside wiring, this program doesn't produce the expected results (t_out1 is empty).We should consider whether to support such programs, and if so, what the best approach is.