ihuzenko commented on a change in pull request #1397: [CALCITE-3115] Cannot add
JdbcRules which have different JdbcConvention to same VolcanoPlanner's RuleSet.
URL: https://github.com/apache/calcite/pull/1397#discussion_r316735641
##########
File path: core/src/main/java/org/apache/calcite/adapter/jdbc/JdbcRules.java
##########
@@ -262,6 +263,17 @@ private JdbcRules() {
this(clazz, (Predicate<R>) predicate, in, out, relBuilderFactory,
description);
}
+
+ /**
+ * Creates name for child JdbcConverter rules in format:
+ * RuleName(out:CONVENTION_NAME)
+ *
+ * @param out output convention
+ * @return rule name
+ */
+ protected static String getRuleName(Class<?> clazz, JdbcConvention out) {
+ return String.format(Locale.ROOT, "%s(out:%s)", clazz.getSimpleName(),
out);
+ }
Review comment:
This pattern was chosen by me, because it's similar to the one in
```ConverterRule``` constructor:
```
description == null
? "ConverterRule(in:" + in + ",out:" + out + ")"
: description)
```
Only difference in my code is that I didn't use **in** rel trait argument,
since for jdbc rules it's the same everywhere. I can move the method to
```ConverterRule```, but then ignoring ```in``` argument won't be good I think.
So, should I move the method up in the hierarchy with pattern like
```RuleName(in:" + in + ",out:" + out + ")"``` ?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
