-
Notifications
You must be signed in to change notification settings - Fork 1k
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
feat: use coherent naming scheme for generated java code #3417
Conversation
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.
Thanks @agavra -- LGTM with a question inline.
final List<Column> suppliedKey = keyBuilder.build(); | ||
|
||
final List<Column> key = suppliedKey.isEmpty() | ||
? IMPLICIT_KEY_SCHEMA | ||
: suppliedKey; | ||
|
||
return new LogicalSchema( | ||
METADATA_SCHEMA, | ||
metadata.isEmpty() ? METADATA_SCHEMA : metadata, |
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.
Not entirely understanding this change. Is the idea that external Builder instances will continue to use the default metadata schema, but that internal Builder instances will copy the metadata around?
The metadata schema is not updated anywhere, is it? So this is equivalent to always returning the default metadata schema, except "safer" in that we copy when we should. Is that correct?
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.
I thought the comment would help here - basically the metadata is actually updated when we add/remove aliases :( I'll be trying to remove that in the long run.
// used only for internal copy (keeps the alias from the original schema)
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.
Ah got'cha. And all of that is still managed by this class, which is why the metadataColumns()
method can be private. Thanks for clarifying!
Hey @agavra , could you give an example of some generated code that's changed because of these changes? |
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.
Thanks @agavra
I've got no issue with the core change to the code generation - this is a great improvement IMHO.
However, I do have an objection to the change to Column
. It smells! See comment inline...
* Unknown index, used for key columns that have not | ||
* been resolved to a value column. | ||
*/ | ||
public static final int UNKNOWN_IDX = -1; |
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.
why not just have OptionalInt index
, rather than some magic special number?
private final ColumnRef ref; | ||
private final SqlType type; | ||
private final int index; |
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.
Hummm.... index
is not included in equals
and hashCode
.
I'm guessing you're doing this as otherwise lots of tests and other things start to fail, right?
These feels wrong and will likely cause bugs or at least tests that don't test what people think they do.
It looks like the functionality in this PR can be implemented without the change to this class.
I suggest one of the following approaches:
- Don't make this change to this class, and just continue to use the existing
valueColumnIndex
impl inLogicalSchema
for now. - Make this change, but implement
hashCode
andequals
properly. As part of this we should avoid building instances ofColumn
to pass to things where we don't care about the index. Escentially, if a method only cares about the name and type, then that's not aColumn
with this change. e.g. the following is an example of existing code that would become a misuse ofColumn
. ThedoFindKeyColumn
method should take the name and type as separate params:
return doFindKeyColumn(selectExpressions, Column.of(keyField.name(), keyField.type()))
.map(field -> LegacyField.of(ColumnName.of(field.fullName()), field.type()));
- Leave column as-is, but change
LogicalSchema
to track the indexes better. - Build the field -> index mapping just in the java generation code.
- Something else.
TBH, there's a lot of changes going in around the logical schema, columns, and copying of rowkey and rowtime into the value schema. Once the dust settles on all this good refactoring it might well be that the only place that cares about indexes is the java code builder. Hence, I'd urge you to just go with option 1 above for now.
@@ -51,7 +51,8 @@ public void shouldImplementEqualsProperly() { | |||
new EqualsTester() | |||
.addEqualityGroup( | |||
Column.of(SOME_NAME, SqlTypes.INTEGER), | |||
Column.of(SOME_NAME, SqlTypes.INTEGER) | |||
Column.of(SOME_NAME, SqlTypes.INTEGER), | |||
Column.of(SOME_NAME, SqlTypes.INTEGER).withIndex(1) // index is not considered |
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.
bug! ;)
@@ -180,7 +180,7 @@ private void addParameter(final Column schemaColumn) { | |||
parameters.add(new ParameterType( | |||
SQL_TO_JAVA_TYPE_CONVERTER.toJavaType(schemaColumn.type()), | |||
schemaColumn.fullName(), | |||
schemaColumn.fullName().replace(".", "_"), | |||
CodeGenUtils.paramName(schemaColumn), |
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.
yay
} | ||
|
||
static String paramName(final Column column) { | ||
KsqlPreconditions.checkArgument( |
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.
This throws an KsqlException
which is reserved for user errors. This is not a user error...
@purplefox the sorts of changes can be see in the |
making major change after @big-andy-coates' suggestion
8371eb8
to
57fdecf
Compare
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.
Now that's a lot smaller and more contained!
Thanks @agavra, LGTM
Description
This patch ensures that all generated code uses valid Java identifiers instead of arbitrary column names by generating
varX
whereX
is the column index for the parameter being passed in. Note that the only "real" changes in this PR are inSqlToJavaVisitor
andCodeGenRunner
(both of which are single line changes).As part of this change I also:
Column
also has an indexLogicalSchema.Builder
tracks Column IndicesLogicalSchema
uses the builder to do internal copies to maintain unique indices (when copying metadata/keys into value)Testing done
mvn clean install
Reviewer checklist