[FRG-83] Need scoping of dynamic parameters

[dynamobi-build]

[reporter="zfong", created="Mon, 20 Mar 2006 18:03:28 -0500 (GMT-05:00)"] Currently, dynamic parameters are created during rule processing. This causes problems if a subtree that uses dynamic parameters is duplicated elsewhere in a statement. The following illustrates the problem:

create table t(a int, b int, c int) server sys_column_store_data_server;
create index ita on t(a);
create index itb on t(b);
create view v as select * from t where a = 1 and b = 2;
select * from v v1, v v2;

The select will result in an assert in Fennel when trying to create the same dynamic parameter id a second time.

[dynamobi-build]

[author="jvs", created="Tue, 21 Mar 2006 13:43:56 -0500 (GMT-05:00)"] For a semi-related bug having to do with rel multi-instancing, see FRG-82.

[dynamobi-build]

[author="stephan", created="Tue, 21 Mar 2006 14:15:23 -0500 (GMT-05:00)"] The solution to FRG-82 is implemented in a way that's specific to iterator/fennel conversion, but it sounds like the same kind of scoping problem. I can imagine a more general mechanism for allowing a multi-instanced rel to deal with its separate invocations.

I considered giving IteratorToFennelConverter access to it and its ancestor's JavaRelImplementor.Frame.ordinal. I was going to use the sequence of ancestor rel ordinals as a representation of the I2FC's location in the plan (for the current invocation), generating a key to use with I2FC's new map structures. In the end, the mapRel2Frame doesn't deal with multi-instanced rels -- the first I2FC's Frame is replaced by the second's Frame and I would have needed both Frames to survive since I2FC creates scoped data in implementFennelChild and uses it in toStreamDef.

If that mapRel2Frame deficiency can be resolved, then Frame could be extended to provide rel-specific storage of arbitrary data (something like set/getProperty), probably through methods on JavaRelImplementor. Then if the rel is written to use the Frame to store its location-specific data nothing else special needs to be done. (The data doesn't have to be stored in Frame, but Frame seems a likely candidate to me.)

[dynamobi-build]

[author="jvs", created="Wed, 22 Mar 2006 17:39:39 -0500 (GMT-05:00)"] Just checked in as eigenchange 5947.

Use new method FennelRelImplementor.allocateRelParamId to reserve an ID; use translateParamId to convert it at toStreamDef time. FennelDynamicParamid.intValue() gives you the actual int to write into the streamdef; everywhere else should be changed to use/pass the strong types. Since these are objects now, you can use null instead of having to pass a separate boolean for ignore.

If you merge over to lcs and make the fixes there, the fix won't get back to lu/dev until next time you sync up; I think that's OK.

[dynamobi-build]

[author="zfong", created="Thu, 23 Mar 2006 11:19:38 -0500 (GMT-05:00)"] Fixed to make use of the new dynamic parameter infrastructure that supports scoping of parameters. Changes have been checked into lcs branch in Eigenchange 5955.