Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Implemented
-
None
-
None
-
None
Description
Currently, expressions in the Table API can be defined in two ways. Either via the implicit Scala DSL or via custom strings:
Table revenue = orders .filter("cCountry === 'FRANCE'") .groupBy("cID, cName") .select("cID, cName, revenue.sum AS revSum"); // vs. val revenue = orders .filter('cCountry === "FRANCE") .groupBy('cID, 'cName) .select('cID, 'cName, 'revenue.sum AS 'revSum)
The Java version of the Table API was always treated as a third class citizen.
In the past the string-based expression parser was/is:
- multiple times out of sync with the Scala DSL
- buggy because it was not properly tested
- it blows up the API as every method must accept both representations like select(String) and select(Expression)
- confusing for users because it looks like SQL but is actually only SQL-like
- does not provide JavaDocs or further help in case of parse errors within the IDE, a user can only consult the online documentation
We should discuss alternatives for the string-based expressions and might come up with a DSL-like approach to make the Table API ready for the future.
This issue would be a big design shift for Table API users in Java. We need to discuss if the benefits are worth the change. A first proof-of-concept/design proposal will follow shortly.
Attachments
Issue Links
- mentioned in
-
Page Loading...