[jira] [Commented] (GROOVY-5436) Enable use of parameter list in SQL IN Clause
[ https://issues.apache.org/jira/browse/GROOVY-5436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17127889#comment-17127889 ] Moises Lejter commented on GROOVY-5436: --- Let me add a +1 to this - I just ran into this issue, having assumed that Groovy provided the same support as Spring's JdbcTemplate for a collection as a parameter for an IN clause :(. > Enable use of parameter list in SQL IN Clause > - > > Key: GROOVY-5436 > URL: https://issues.apache.org/jira/browse/GROOVY-5436 > Project: Groovy > Issue Type: Improvement > Components: SQL processing >Affects Versions: 1.8.6 >Reporter: Gerhard Stuhlpfarrer >Priority: Major > > Groovy SQL (groovy.sql.Sql) provides methods to bind an Array of parameters > to sql (e.g. rows, eachRow, execute, executeUpdate, ...). > But you have a problem if you need to pass parameter lists to your sql > statement which has a IN clause. > There exists a workaround for this problem, but this is not very groovy. > see discussions here: > http://groovy.329449.n5.nabble.com/In-operator-in-Groovy-SQL-td4768856.html > http://stackoverflow.com/questions/2861230/what-is-the-best-approach-using-jdbc-for-parameterizing-an-in-clause -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GROOVY-8051) Reference outer class property within inner class closure
[
https://issues.apache.org/jira/browse/GROOVY-8051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17127723#comment-17127723
]
Eric Milles commented on GROOVY-8051:
-
This was resolved by the rewriting of "this" -> "thisObject" ->
"thisObject.this$0" in Groovy 2.5:
https://github.com/apache/groovy/blob/GROOVY_2_5_X/src/main/java/org/codehaus/groovy/classgen/asm/sc/StaticInvocationWriter.java#L376
GROOVY-7970 seems to be the source of the fix and includes discussion regarding
backporting to Groovy 2.4. GROOVY-8051 specifically can be fixed with only the
"if (target.isPublic() && receiver != null)" block in
StaticInvocationWriter#writeDirectMethodCall.
> Reference outer class property within inner class closure
> -
>
> Key: GROOVY-8051
> URL: https://issues.apache.org/jira/browse/GROOVY-8051
> Project: Groovy
> Issue Type: Bug
> Components: Compiler, Static compilation, Static Type Checker
>Affects Versions: 2.4.7, 2.4.8
>Reporter: Daniil Ovchinnikov
>Priority: Major
>
> {code}
> @CompileStatic // works without this @CompileStatic
> class Outer {
> def foo = 1
> Inner createInner() { new Inner() }
> class Inner {
> Closure createClosure() {
> return { foo }
> }
> }
> }
> @CompileStatic
> class Main {
> static void main(String[] args) {
> def i = new Outer().createInner()
> def cl = i.createClosure()
> println cl()
> }
> }
> {code}
> Fail in runtime with:
> {noformat}
> Exception in thread "main"
> org.codehaus.groovy.runtime.typehandling.GroovyCastException:
> Cannot cast object 'Outer$Inner@23e028a9' with class 'Outer$Inner' to class
> 'Outer'
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnSAM(DefaultTypeTransformation.java:405)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnNumber(DefaultTypeTransformation.java:319)
> at
> org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:232)
> at
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.castToType(ScriptBytecodeAdapter.java:603)
> at Outer$Inner$_createClosure_closure1.doCall(innerclassestest.groovy)
> at Outer$Inner$_createClosure_closure1.call(innerclassestest.groovy)
> at Main.main(innerclassestest.groovy:23)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GROOVY-8358) Nested class resolution behaves differently depending on class order
[
https://issues.apache.org/jira/browse/GROOVY-8358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17127559#comment-17127559
]
Daniil Ovchinnikov commented on GROOVY-8358:
[~richardHu] Tell me what is unclear, please.
> Nested class resolution behaves differently depending on class order
>
>
> Key: GROOVY-8358
> URL: https://issues.apache.org/jira/browse/GROOVY-8358
> Project: Groovy
> Issue Type: Bug
>Reporter: Daniil Ovchinnikov
>Priority: Critical
>
> {code}
> package bugs
> class Outer implements OuterI {
> static class Current extends CurrentParent {
> static usage() {
> new Target()
> }
> }
> }
> class CurrentParent implements CurrentParentI {}
> interface CurrentParentI {
> static class Target {}
> }
> interface OuterI {
> static class Target {}
> }
> println Outer.Current.usage() // bugs.OuterI$Target@3eb7fc54
> {code}
> If {{CurrentParent}} definition is moved before {{Outer}}, then {{new
> Target}} will be resolved to {{bugs.CurrentParentI$Target}}:
> {code}
> package bugs
> class CurrentParent implements CurrentParentI {}
> class Outer implements OuterI {
> class Current extends CurrentParent {
> static usage() {
> new Target()
> }
> }
> }
> interface CurrentParentI {
> static class Target {}
> }
> interface OuterI {
> static class Target {}
> }
> println Outer.Current.usage() // bugs.CurrentParentI$Target@3eb7fc54
> {code}
> Moving classes must not affect results of compilation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
