-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Migrate JMX connector to new APIs #511
Conversation
7fb01cb
to
79046a4
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.
import io.prestosql.spi.connector.Constraint; | ||
import io.prestosql.spi.connector.SchemaTableName; | ||
import io.prestosql.spi.connector.SchemaTablePrefix; | ||
import io.prestosql.spi.connector.*; |
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.
We do not use star imports.
Hopefully importing https://github.com/airlift/codestyle into Intellij should get you the right configuration.
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! Fixed it.
presto-jmx/src/main/java/io/prestosql/plugin/jmx/JmxMetadata.java
Outdated
Show resolved
Hide resolved
79046a4
to
29efa7d
Compare
@findepi Thanks for your review! I fixed code and updated the title of this pull request. Currently some test cases are commented out because it seems that there is no way to give predicate to SplitManager without deprecated version of |
// for (Node node : nodes) { | ||
// String nodeIdentifier = node.getNodeIdentifier(); | ||
// | ||
// // TODO Is there any way to give predicate to SplitManager without deprecated version of getSplits()? |
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.
The new API doesn't yet support pushing down predicates. It's something we're adding as part of #18. We'll add a version of the API that takes a Constraint
object like getTableLayout
does today to ease migration. We should probably wait to complete and merge this PR until that gets in (which will happen soon), otherwise, we're removing existing features for this connector.
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 for the explanation! I understand it isn't a time to migrate connectors yet. I'm waiting for Constraint
to be added.
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! I'm going to resume working on this pull request. |
ab2ed22
to
c04d402
Compare
public static class Node | ||
{ | ||
private String identifier; | ||
private HostAddress address; |
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 think these fields should be private final
.
Optional<ConstraintApplicationResult<ConnectorTableHandle>> result = metadata.applyFilter(handle, new Constraint(TupleDomain.all())); | ||
|
||
assertTrue(result.isPresent()); | ||
assertTrue(((JmxTableHandle) result.get().getHandle()).getNodes().size() == 3); |
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.
It would be better to use assertEquals
when we check two values. L138 is also the same.
|
||
private static JmxTableHandle.Node createTestingNode(String hostname) | ||
{ | ||
return new JmxTableHandle.Node(hostname, HostAddress.fromString(format("%s:8080", hostname))); |
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.
HostAddress.fromParts
is simpler than concating hostname and port.
return new JmxTableHandle.Node(hostname, HostAddress.fromParts(hostname, 8080));
.map(node -> new JmxSplit(ImmutableList.of(node.getHostAndPort()))) | ||
.collect(toList()); | ||
List<ConnectorSplit> splits = tableHandle.getNodes().stream() | ||
.map(node -> new JmxSplit(ImmutableList.of(node.getAddress()))).collect(toList()); |
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.
Move .collect(toList());
to next line.
Also, we can use .collect(toImmutableList());
and then change L40 to
return new FixedSplitSource(splits);
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.
Move .collect(toList()); to next line.
Do we have a specific regulation about putting new lines? Actually, I have a similar code in JmxMetadata
as follows. I'm wondering if I have to put new lines before .map
and .collect
.
private List<JmxTableHandle.Node> getAllNodes()
{
return nodeManager.getAllNodes().stream().map(node -> new JmxTableHandle.Node(node.getNodeIdentifier(), node.getHostAndPort())).collect(toList());
}
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.
When the statement is simple, one line is fine. When you break a line after .stream()
, subsequent each operations should be independent line as original code was. (There's no 'specific' regulation as far as I know).
The getAllNodes
looks little long for one line and there's only one statement in the method, so putting new lines looks reasonable to me.
ConnectorSession session, | ||
ConnectorSplit split, | ||
ConnectorTableHandle table, | ||
List<? extends ColumnHandle> columns) |
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 change looks just fixing style, but the commit title is Fix warning in JmxRecordSetProvider
. What is the waring message (line length)?
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 can't remember. Let me revert this change.
}) | ||
.collect(toList()); | ||
|
||
JmxTableHandle newTaleHandle = new JmxTableHandle(tableHandle.getTableName(), tableHandle.getObjectNames(), tableHandle.getColumnHandles(), tableHandle.isLiveData(), nodes); |
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.
Typo newTaleHandle
→ newTableHandle
3cc894c
to
8967050
Compare
@martint I finished to migrate the JMX connector node selection pushdown to |
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! That's a step in the right direction, but as a I mentioned in the comment above, it'd be better to hold on to the filter in the table handle instead of the list of filtered nodes (which can be large for large installations). and filter them at the point splits are generated.
|
||
@JsonCreator | ||
public JmxTableHandle( | ||
@JsonProperty("tableName") SchemaTableName tableName, | ||
@JsonProperty("objectNames") List<String> objectNames, | ||
@JsonProperty("columnHandles") List<JmxColumnHandle> columnHandles, | ||
@JsonProperty("liveData") boolean liveData, | ||
@JsonProperty("addresses") List<HostAddress> addresses) | ||
@JsonProperty("nodes") List<Node> nodes) |
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 hold on to the list of nodes in the TableHandle? I'd be better to just hold on to the predicate and filter them out during split generation.
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.
In my understanding, to hold the predicate ( TupleDomain
or Map<ColumnHandle, Domain>
) in the TableHandle, we need to make all classes held in the ValueSet
serializable to JSON. Is this 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.
Oops, I didn't know TupleDomain
is always JSON serializable. I fixed to hold TupleDomain
in TableHandle
instead of the list of node.
@Override | ||
public ConnectorTableProperties getTableProperties(ConnectorSession session, ConnectorTableHandle table) | ||
{ | ||
return new ConnectorTableProperties( |
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 can use the no-args constructor, which does the same thing
e0d60cb
to
1e6e77d
Compare
@takezoe, can you rebase on master and remove the merge commits? They are confusing github and it's not displaying the actual differences with respect to the base commit. |
Sure, I rebased on master branch without merge commits. |
return ImmutableList.of(new ConnectorTableLayoutResult(layout, constraint.getSummary())); | ||
} | ||
JmxTableHandle tableHandle = (JmxTableHandle) handle; | ||
TupleDomain<ColumnHandle> predicate = constraint.getSummary(); |
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.
applyFilter
can get called multiple times throughout the optimization process. Connectors need to ensure that they "remember" the result of previous applications. Also, if applying the filter did not have any effect, the method needs to return Optional.empty()
. Otherwise, the optimizer may loop forever.
See https://github.com/prestosql/presto/blob/master/presto-base-jdbc/src/main/java/io/prestosql/plugin/jdbc/JdbcMetadata.java#L86 for an example.
return new ConnectorTableLayout(handle); | ||
JmxTableHandle newTableHandle = new JmxTableHandle(tableHandle.getTableName(), tableHandle.getObjectNames(), tableHandle.getColumnHandles(), tableHandle.isLiveData(), predicate); | ||
|
||
return Optional.of(new ConstraintApplicationResult(newTableHandle, predicate)); |
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.
If the connector guarantees the results are going to satisfy the constraint, it's not necessary to return the predicate in the ConstraintApplicationResult
. It can just indicate TupleDomain.ALL
.
presto-jmx/src/main/java/io/prestosql/plugin/jmx/JmxTableHandle.java
Outdated
Show resolved
Hide resolved
@martint Thanks for your review again. Fixed to return |
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.
Sorry for the delay. This looks great. Just a few minor comments, mostly around unrelated changes.
Can you squash all commits? I'll merge it then.
|
||
//TODO is there a better way to get the node column? |
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.
unrelated change?
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.
Oh, sorry. Reverted.
Optional<JmxColumnHandle> nodeColumnHandle = tableHandle.getColumnHandles().stream() | ||
.filter(jmxColumnHandle -> jmxColumnHandle.getColumnName().equals(NODE_COLUMN_NAME)) | ||
.findFirst(); | ||
|
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.
Unrelated formatting change.
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.
True. Reverted too.
.addEquivalentGroup( | ||
new JmxTableHandle(SCHEMA_TABLE_NAME, ImmutableList.of("name"), COLUMNS, false), | ||
new JmxTableHandle(SCHEMA_TABLE_NAME, ImmutableList.of("name"), COLUMNS, false)) | ||
new JmxTableHandle(SCHEMA_TABLE_NAME, ImmutableList.of("nameX"), COLUMNS, true, TupleDomain.all()), |
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 the name change here?
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 is diff magic. I didn't change the name, just added new arguments. "name" patterns are coverd by preceding 2 equivalent groups.
.addEquivalentGroup( | ||
new JmxTableHandle(SCHEMA_TABLE_NAME, ImmutableList.of("nameX"), COLUMNS, false), |
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 the name change here?
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.
Same as above.
Fix warning in JmxRecordSetProvider Removed unused import statements Migrate node column pushdown to applyFilter Fix compilation error Fix JmxTableHandle to have all nodes initially then filter them at applyFilter Add tests for JmxMetadata#applyFilter() Review feedback Add TupleDomain to JmxTableHandle Fix JmxMetadata.getTableProperties to use no-args constructor Fix compilation error Return empty from applyFilter if TableHandle has same constraint Split TupleDomain to node column and others Fix Json property name and error message of nodeFilter Post review feedback
@martint Thanks for your comment! Fixed and squashed. |
Merged. Thanks for your contribution! |
No description provided.