After creating a new Query Table, when running the application from Studio or the command-line we see an error that looks like this:

2019-01-08 20:22:57.140000+0000 [96350:EventFlow Fragment] ERROR com.tibco.ep.sb.rt.launcher.EventFlowFragment: java.lang.Exception: 
Fragment com.company.bizapp.TheBizApp terminated with status -1: Aborting transaction default: java.lang.RuntimeException: 
com.streambase.sb.StreamBaseException: java.lang.NoSuchFieldException: f9_value: java.lang.RuntimeException: 
com.streambase.sb.StreamBaseException: java.lang.NoSuchFieldException: f9_value: java.lang.NoSuchFieldException: f9_value: 
java.lang.NoSuchFieldException: f9_value
java.lang.Exception: Fragment com.company.bizapp.TheBizApp terminated with status -1
	at com.tibco.ep.sb.rt.launcher.Fragment.run(Fragment.java:139)
Caused by: com.kabira.platform.Transaction$InvocationRunException: Aborting transaction default

This is caused by a set of known defects in early versions of TIBCO StreamBase 10 and TIBCO Streaming where a field of a complex type (a tuple or list of tuples) which was acceptable in StreamBase 7 causes a compilation error in version 10. This is due to a regression when the Query Table feature was reimplemented on the new runtime platform.

The "f9_value" internal field name varies depending on where the complex field is found in the schema.

Complex fields in the schema will not cause a compilation error when the Query Table is stored in memory, but may raise this error and cause the server to fail to start for tables stored either "On disk" or "In transactional memory".

Please check the Release Notes to see if this issue is resolved in the product version you are using or a prior release.

The workaround is to use a string-type field and a named schema of the complex field's type and convert the list to a JSON string using an expression like 'tojson(tuple(myList) as L)'. Store the string in the table and convert it back using 'parsejson(tuple(list(ComplexTupleSchema())),asJSON).expr_0'. 

The tojson() and parsejson() functions work on a whole tuple and not just a single field, which is why the type is converted to tuple for these operations.

Workaround guidance