Hi,
I am working through some issues with data types. Here are some questions that have come up:
- Is there a known issue with using the LIST data type?
- In my online data loading I seem to get values getting jumbled up between fields that aren’t even on the same vertex type.
- Basic STRING COMPRESS types seem to work fine, only using it inside a LIST seems to be affected.
- Is there a better / more efficient way to represent a UUID than as a STRING , e.g. using FIXED_BINARY(16) ?
- If using FIXED_BINARY , is ORDER, WHERE , etc. supported?
- When using SET.size() I get the error “this feature is not yet available in batch mode queries”. When will it be available?
- Is there a way to test the content of a LIST / LIST for certain values?
- I need to use a LIST because I need the output to retain order characteristics, but I need to use predicates that test for value overlap.
- The way I’d expect this to work is something like ((list_type_attribute INTERSECT list_type_query_parameter).size() > 0)
- Is there planned support for using BOOL types with the ORDER clause?
- The workaround of using an INT to represent all BOOL values seems wasteful.
- When is support planned for PRINT results from interpreted queries maintaining the ORDER of the SELECT they represent?
- Are there any plans for a percentile accumulator that supports arbitrary percentiles?
- e.g. PercentileAccum(1, 5, 50, 95, 99)
- Are there any plans to support DATETIME in the existing accumulators?
- e.g. MinAccum
- Are there any plans to support formatting DATETIME output results (specifically with ISO8601 formats)?
- Are there any plans to add escaping/quoting identifiers to the language generally or the PRINT statement specifically?
- It’s pretty limiting that all GSQL reserved keywords block using those strings as keys in PRINT results.
- In a generic query generator we have to namespace everything (vertex names, edge names, AS names, etc.) to avoid accidentally hitting keywords).
- The grand-daddy of them all: is there any plan to introduce an OPTION type?
- Explicit NULL handling is a great idea, and it makes some sense that TigerGraph would ban NULLs to avoid it.
- However, the workaround of including a secondary shadow attribute to indicate presence is very painful with large numbers of attributes.
- Being able to wrap any other data type in an option type that could be handled as a monad would provide the flexibility of natively representing “missing” values while ensuring that GSQL written against those types properly handles the missing cases.
- e.g.
- definition: OPTION some_attribute DEFAULT NONE (or DEFAULT SOME(999) )
- predicate: WHERE tgt.some_attribute.contains(999)
- aggregate: AvgAccum<OPTION> // does nothing when value is NONE
- etc.
Thanks in advance!