Documentation   >   Network database   >   Network Query Language - Extensions
 
Overview
Manipulation
Modification
NQL Extension
Java Client


Overview
There are 2 types of NQL extensions: filters and behave clause. They both have the same purpose (extend querying) but slightly different technically.

Pipe processing
You can pass results from one query right on input to other one. It's similar to | (pipe) command in Linux/Unix. Have you ever run "ps ax | grep java" on Linux ?
SELECT (...)/(...)/(...)  |  SELECT (...)  

Filters
SELECT (referer like '*google*') / FILTER('do some stuff') / (name='session') limit 20
FILTER() VS BEHAVE
BEHAVE is executed in separate pipe. So, it waits until whole output network from previous pipe are ready.
Filter is applied during query execution stream and does not wait when whole output data generated.
So, in queries below filter is applied just to 20 entities but Behave is applied to whole entities returned by previous pipe (can be millions entities).
SELECT (referer like '*google*') / FILTER('do some stuff') limit 20
SELECT (referer like '*google*') | BEHAVE('do some stuff') limit 20

Behave clause
You can write own pieces of code and run it inside query. BEHAVE(...) operand is used for such solutions.
SELECT (...)  |  BEHAVE(...)  

or

SELECT (last_name='Smith' AND SSN='123456789') 
| BEHAVE (flow='my.package.GetPaymentHistory-Start') 
| SELECT (name='payment' AND overdraft='true')   
In example above we found a person in a storage pass it to custom behavior (implemented in flow my.package.GetPaymentHistory-Start) which get payment history for the person and then filter out overdraft payments.

There is ability to 'transform' network to a table and run SQL command against it. Let's extend query above and get total amount of overdraft payments.
SELECT (last_name='Smith' AND SSN='123456789') 
| BEHAVE(flow='my.package.GetPaymentHistory-Start') 
| SELECT (name='payment' AND overdraft='true')   
| SQL (query="select SUM(amount) from table where name='payment' ")

Virtual entities/relations
Connections/relations can be persistent (in storage) or virtual (calculated runtime). What is useful for learning/meaning software. E.g. analyst analyze some data - create some new virtual connections. Then if new virtual data is useful - persist them.
Dynamic/virtual relations can be created using 'BEHAVE' clause.
Powered by ESG