[FRG-82] assertion in setFarragoTransformClassName

[dynamobi-build]

[reporter="jvs", created="Sat, 18 Mar 2006 15:03:06 -0500 (GMT-05:00)"] Use dt/dev@5871 to reproduce.

SELECT "GoodView2"."FileName", "GoodView2"."LineNumber", "GoodView2"."RuleId", "GoodView2"."Message", "GoodView6"."FileName" AS "FileName0", "GoodView6"."LineNumber" AS "LineNumber0", "GoodView6"."RuleId" AS "RuleId0", "GoodView6"."Message" AS "Message0"
FROM (select * from (select cast(null as VARCHAR(1024)) as "FileName", cast(null as INTEGER) as "LineNumber", cast(null as INTEGER) as "RuleId", cast(null as VARCHAR(2048)) as "Message" from (values(0))) as c) AS "GoodView2",
            (select * from (select cast(null as VARCHAR(1024)) as "FileName", cast(null as INTEGER) as "LineNumber", cast(null as INTEGER) as "RuleId", cast(null as VARCHAR(2048)) as "Message" from (values(0))) as c) AS "GoodView6"

yields

Error: java.lang.AssertionError: null (state=,code=0)
net.sf.farrago.util.FarragoUtil$FarragoSqlException: java.lang.AssertionError: null
        at net.sf.farrago.query.IteratorToFennelConverter.setFarragoTransformClassName(IteratorToFennelConverter.java:453)
        at net.sf.farrago.query.IteratorToFennelConverter.implementFennelChild(IteratorToFennelConverter.java:404)
        at net.sf.farrago.query.FarragoRelImplementor.visitChildInternal(FarragoRelImplementor.java:138)
        at org.eigenbase.oj.rel.JavaRelImplementor.visitChild(JavaRelImplementor.java:355)
        at net.sf.farrago.query.FennelDoubleRel.implementFennelChild(FennelDoubleRel.java:104)
        at net.sf.farrago.query.FarragoRelImplementor.visitChildInternal(FarragoRelImplementor.java:138)
        at org.eigenbase.oj.rel.JavaRelImplementor.visitChild(JavaRelImplementor.java:355)
        at net.sf.farrago.query.FennelToIteratorConverter.implement(FennelToIteratorConverter.java:161)
        at org.eigenbase.oj.rel.JavaRelImplementor.visitChildInternal(JavaRelImplementor.java:387)
        at net.sf.farrago.query.FarragoRelImplementor.visitChildInternal(FarragoRelImplementor.java:140)
        at org.eigenbase.oj.rel.JavaRelImplementor.visitChild(JavaRelImplementor.java:355)
        at org.eigenbase.oj.rel.JavaRelImplementor.visitJavaChild(JavaRelImplementor.java:343)
        at org.eigenbase.oj.rel.JavaRelImplementor.implementRoot(JavaRelImplementor.java:404)
        at net.sf.farrago.query.FarragoRelImplementor.implementRoot(FarragoRelImplementor.java:283)
        at org.eigenbase.oj.stmt.OJPreparingStmt.implement(OJPreparingStmt.java:301)
        at org.eigenbase.oj.stmt.OJPreparingStmt.prepareSql(OJPreparingStmt.java:256)
        at net.sf.farrago.query.FarragoPreparingStmt.prepare(FarragoPreparingStmt.java:237)
        at net.sf.farrago.db.FarragoDatabase$2.initializeEntry(FarragoDatabase.java:664)
        at net.sf.farrago.util.FarragoObjectCache.pin(FarragoObjectCache.java:157)
        at net.sf.farrago.db.FarragoDatabase.prepareStmtImpl(FarragoDatabase.java:674)
        at net.sf.farrago.db.FarragoDatabase.prepareStmt(FarragoDatabase.java:554)
        at net.sf.farrago.db.FarragoDbSession.prepareImpl(FarragoDbSession.java:810)
        at net.sf.farrago.db.FarragoDbSession.prepare(FarragoDbSession.java:761)at net.sf.farrago.db.FarragoDbStmtContext.prepare(FarragoDbStmtContext.java:156)
        at net.sf.farrago.jdbc.engine.FarragoJdbcEngineStatement.execute(FarragoJdbcEngineStatement.java:104)
        at sqlline.SqlLine$Commands.execute(Unknown Source)
        at sqlline.SqlLine$Commands.sql(Unknown Source)
        at sqlline.SqlLine.dispatch(Unknown Source)
        at sqlline.SqlLine.runCommands(Unknown Source)
        at sqlline.SqlLine$Commands.run(Unknown Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at sqlline.SqlLine$ReflectiveCommandHandler.execute(Unknown Source)
        at sqlline.SqlLine.dispatch(Unknown Source)
        at sqlline.SqlLine.begin(Unknown Source)
        at sqlline.SqlLine.mainWithInputRedirection(Unknown Source)
        at sqlline.SqlLine.main(Unknown Source)

explain plan shows two IteratorToFennels as children of the FennelCartesianProductRel, then a FennelToIteratorConverter on top of that; nothing that complicated despite the SQL ugliness.

[dynamobi-build]

[author="stephan", created="Sun, 19 Mar 2006 11:54:06 -0500 (GMT-05:00)"] I'm guessing the planner is recognizing that it has two identical IteratorToFennelConverters and is only allowing one instance to exist, but using it twice. At first glance, I can just remove the assertion and let it generate two classes that do the same thing, which is what we want.

However, that's probably too simplistic: something bad will probably happen when a Fennel table is substituted for the values(0) clause. That would be two I2FC and two F2IC, represented as single instance of each by the planner, but it needs to generate both sets.

Will take a crack at fixing it on 3/21.

[dynamobi-build]

[author="stephan", created="Tue, 21 Mar 2006 13:35:39 -0500 (GMT-05:00)"] Fixed in //open/dt/dev @ 5918.

As I suspected, the IteratorToFennelConverter instance was being re-used. Modified it's implementation to handle re-use. Added test cases to validate re-use of IteratorToFennelConverters.

[dynamobi-build]

[author="jvs", created="Tue, 21 Mar 2006 13:43:12 -0500 (GMT-05:00)"] Thanks. For a semi-related rel multi-instancing design flaw exposed by LucidDB's generation of dynamic parameters in plans, see FRG-83, which I'm planning to take a crack at once I integrate over your fix for FRG-82. (Nothing to do with your Java sandwich changes; this flaw has been there all along.) It's more complicated for dynamic params because they have a notion of scope.