New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BEAM-2520] add UDF/UDAF in BeamSql.query/simpleQuery #3491
Conversation
R: @xumingming @lukecwik |
return new QueryTransform(sqlQuery); | ||
|
||
public static QueryTransform query(String sqlQuery) { | ||
return new AutoValue_BeamSql_QueryTransform.Builder() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
new AutoValue_BeamSql_QueryTransform.Builder()
=> new QueryTransform.builder()
?
simpleQuery(String sqlQuery) throws Exception { | ||
return new SimpleQueryTransform(sqlQuery); | ||
public static SimpleQueryTransform simpleQuery(String sqlQuery) throws Exception { | ||
return new AutoValue_BeamSql_SimpleQueryTransform.Builder() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
new AutoValue_BeamSql_SimpleQueryTransform.Builder()
=> SimpleQueryTransform.builder()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM (except two small issues.)
Good point, however seems the method of |
Seems different from auto-value's usage convention: https://github.com/google/auto/blob/master/value/userguide/builders.md |
I quote: public void testAnimal() {
Animal dog = Animal.builder().setName("dog").setNumberOfLegs(4).build();
assertEquals("dog", dog.name());
assertEquals(4, dog.numberOfLegs());
// You probably don't need to write assertions like these; just illustrating.
assertTrue(
Animal.builder().setName("dog").setNumberOfLegs(4).build().equals(dog));
assertFalse(
Animal.builder().setName("cat").setNumberOfLegs(4).build().equals(dog));
assertFalse(
Animal.builder().setName("dog").setNumberOfLegs(2).build().equals(dog));
assertEquals("Animal{name=dog, numberOfLegs=4}", dog.toString());
} |
--update interesting, the code of @lukecwik any comments? |
Indeed interesting :) |
@takidau any suggestion which one is prefered in AutoValue?
OR
|
Re builder vs toBuilder, perhaps I'm misunderstanding the question, but they serve different purposes, don't they? I do prefer defining a static builder() method to directly invoking the generated AutoValue_BeamSql_SimpleQueryTransform.Builder() constructor (thought we seem to have both patterns in the Beam codebase currently). |
return PCollectionTuple.of(new TupleTag<BeamSqlRow>(PCOLLECTION_TABLE_NAME), input) | ||
.apply(new QueryTransform(sqlQuery, sqlEnv)); | ||
.apply(new AutoValue_BeamSql_QueryTransform.Builder() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be reduced to .apply(toBuilder().build())
as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ping on this comment, since it wasn't addressed or answered. Can't this be simplified?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
missed this line, just update.
Thanks @takidau for your advise, updated |
/** | ||
* register a UDF function used in this query. | ||
*/ | ||
public QueryTransform withUdf(String functionName, Class<?> clazz, String methodName){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it necessary to support having arbitrarily named (and potentially multiple) UDF methods on a single class? Why not just have a simply BeamSqlUdf interface you must implement? And why not accept a lambda?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-
Is it necessary to support having arbitrarily named (and potentially multiple) UDF methods on a single class?
[Mingmin]: I would like to keep the capacity to put similar or related methods together. -
Why not just have a simply BeamSqlUdf interface you must implement?
[Mingmin]: That's how we do with UDAF, UDF is a little different as it may have variable, even optional parameters. Annotation (likeDoFn
) sounds a solution but the existing definition is more simple IMO. -
And why not accept a lambda?
[Mingmin]: I remember Beam is still on JDK 7, --sorry that I may miss something.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Okay
- We may want to revisit this when we do a holistic API review before merge to master, but fine for now then.
- That's true, but for Java 8 users it'd be nice to have an overload supporting a lambda. Not necessary for this PR though.
Looks like there are build issues, can you please fix? Also, regarding the change in |
update AutoValue builder() update with methods update Builder/build in AutoValue rebase simplify AutoValue
rebased to fix the compile issue.
Regarding to the interface of UDF, your concern is reasonable, created BEAM-2609 for further discussion. |
Thanks for the explanation on the toBuilder question, and for opening the Jira. Merging. |
Merged, feel free to close. |
No description provided.