If two client/server roundtrips are overkill, the small bit of decision logic could also be put into a server-side action that issues the first and second query on the server side, avoiding the extra roundtrip. Obviously that means two queries instead of one, but it might be more efficient. have the application issue a dedicated second query, based on the return value of the first in the first query, fetch the value that would have driven the SWITCH condition In this case it might even be better to split the one query into two: So currently I can't think of something sensible that supports "real" control flow and allows for efficient execution at the same time. The following SWITCH would thus need to execute all the subqueries first and then pick the correct branch, which isn't ideal:Īdding "real" control flow functionality with conditional executes will make query optimization and distribution in the cluster much much harder. The problem is that if subqueries are passed as function parameters, they will need to be executed. In general, these functions would also work if the expressions would be subqueries. LET a = IF(x = 1, 'is one', 'is not one') Here are two examples how they could work: There is one very important difference though: Both functions would work in case the different branches are just simple expressions. A potential SWITCH() function could be the equivalent to a switch/case statement in a programming language. You're right, a potential IF() function would be the function equivalent to the ternary operator. RETURN SWITCH(value, cases, defaultValue) RETURN IF(someCondition, trueValue, falseValue) I think the only sensible way to have if/then/else or switch/caseįunctionality in AQL is by adding them as functions, e.g. There might also beįurther side-effects of control flow that would disable optimizations. In the above query, index usage would be disabled if the conditionĭepends on the variable produced by the FOR loop. This would be reallyĪllowing control flow on sub-levels would also be problematic. ForĮxample, in the above case, the query would become either a retrieval orĪ removal query, depending on the condition. Would make query plan execution and distribution a nightmare. The reason for not introducing "real" control flow statements is that it Into AQL with dedicated statements, at least not something full-featured We have decided to not introduce too much control flow logic We have refactored a lot of the AQL internals in the devel branch
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |