Java client library -- relating interactions from multiple streams back to their definitions?


#1

I 'm looking at the Java client library example file LiveStream.java.

Where I want to get to with this is to be able to create an arbitrary number of definitions, and associate results which come back via their streams with the appropriate definition, so the results can be stored in a database with a key identifying which query led to that data being found. This will of course eventually be automated… but a trivial hardcoded example, starting from the LiveStream.java source file, will demonstrate the workflow I’m describing…

Definition def1 = user.createDefinition("interaction.type == \"twitter\" and (interaction.content contains \"cat\")"); Definition def2 = user.createDefinition("interaction.type == \"twitter\" and (interaction.content contains \"dog\")");
        StreamConsumer consumer1 = def1.getConsumer(StreamConsumer.TYPE_HTTP, new LiveStream());
        StreamConsumer consumer2 = def2.getConsumer(StreamConsumer.TYPE_HTTP, new LiveStream());
	
        consumer1.consume();
        consumer2.consume();

All well and good – data comes back for both, but there’s apparently no way within the onInteraction method, to identify WHICH Definition led to a specific Interaction being returned – so I can’t associate each Interaction with its correct Definition – either ‘cat’ or ‘dog’-based!

All the fields in StreamConsumer are Protected, so I guess they’re not meant to be accessed outside the client library Package – which makes me assume I’m missing the ‘proper’ way to relate Interactions back to their Definitions. My use-case must be a very common one, so please point me at the correct pattern/example.

All help appreciated

D

ps the and other markup tags don’t seem to work as advertised in your forums?


#2

You would want to use our tag keyword and stream keyword in your CSDL. Take a look at this example - note how each of the streams are kept separately from each other, then interactions are appropriately tagged depending on which stream they came from.


#3

ok I can see that the tag keyword is what I want here (thanks!), but can you explain who I also need to ADD a return clause to avoid getting a syntax error?

WITHOUT the tag keyword I could use

{interaction.type == “twitter” and (interaction.content contains “cat”)}

but WITH the tag keyword it seems I need

   tag \"cats\" {interaction.type == \"twitter\" and (interaction.content contains \"cat\")} return  {interaction.type == \"twitter\" and (interaction.content contains \"cat\")}

9ie it works if i duplicate the filter criteria into the return…

What’s the minimal (or most efficient, or cheapest :wink: syntax needed to add the tag keyword and why is the ‘return’ suddenly necessary? What would be the RECOMMENDED way of rewriting that CSDL so that the tag still works?

Thanks again for such a quick reply!

D


#4

…actually, no i get it – it will be more efficient to do this as one loooooong CSDL query and use tags to identify which ‘rule’ triggered the result. Got it. Is there any practical restriction on total length in statements or bytes, of a CSDL query? I can’t find mention os such in the docs…

Thanks again

D


#5

There are a number of ways you can achieve the same result with tagging. For a trivial example like the one described here, the following CSDL would probably make the most sense:

tag "cat" { interaction.content contains "cat" }

tag "dog" { interaction.content contains "dog" }

return {

    interaction.content contains_any "cat, dog" and interaction.type == "twitter"

}

 

For more complex streams, you may want to keep each stream separated. In this case, use the tag keyword along with the stream keyword:

 

tag "cat" { stream "123456789" }

tag "dog" { stream "567891234" }

return {

    stream "123456789" or

    stream "567891234"

}

 

The cheapest way to write CSDL is to combine all your search terms as much as possible (in the same way as the first example). Take a look at our Understanding Billing page for more information about how we charge for streams.

CSDL rules are limited to a maximum size of 1MB. This is typically around 90,000 keywords. This is mentioned on our Advanced Features page