[ 
http://issues.apache.org/jira/browse/DERBY-1633?page=comments#action_12428435 ] 
            
Rick Hillegas commented on DERBY-1633:
--------------------------------------

Thanks for the extra explanation, Army. I think I understand the problem better 
now.

I have one issue with this patch: In at least one place (Predicate.skipRemap()) 
your comments call out certain assumptions about the kinds of queries which 
take this code path. Some day those assumptions may break. When they do, the 
customer will see a very unhelpful diagnostic (in this case, a casting 
exception). I would like to see this code react more defensively, either 
raising a friendlier exception or, preferably, selecting a different albeit 
less optimal plan. I'm concerned that this regression is itself a symptom of a 
missed opportunity to validate our assumptions.

I'd also appreciate it if Satheesh could review this patch. He reviewed the 
original work, DERBY-805, which introduced this regression. I think he is well 
placed to analyze subtle problems which may be lurking in this tricky code.

Thanks again for your extensive explanations both in the code and in this JIRA.

> Regression: The fields of views are not being calculated properly since 
> 10.1.2.4
> --------------------------------------------------------------------------------
>
>                 Key: DERBY-1633
>                 URL: http://issues.apache.org/jira/browse/DERBY-1633
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.1.3.0, 10.1.3.1
>         Environment: 2.8 GHZ dual PIV on Windows XP SP2, 2 GB memory
>            Reporter: Prasenjit Sarkar
>         Assigned To: A B
>             Fix For: 10.2.0.0
>
>         Attachments: d1633_repro.sql, d1633_v1_reviewOnly.patch, 
> d1633_v2.patch, DERBY-1633_v1.html, DERBY-1633_v2.html
>
>
> Database can be assumed to be same as in Derby - 1205 Jira issue
> SELECT PORT1.PORT_ID FROM T_RES_PORT PORT1, T_VIEW_ENTITY2PORT ENTITY2PORT 
> WHERE ENTITY2PORT.PORT_ID = PORT1.PORT_ID
> This works fine in 10.1.2.1 but fails thereafter complaining that Comparison 
> between INTEGER and CHAR is not supported
> for some reason, it thinks one of the PORT_ID columns is a character, when in 
> reality both are integers.
>               SELECT DISTINCT 
>                   ZONE.ZONE_ID ZONE_ID, 
>                        PORT2ZONE.ZONE_MEMBER_ID  
>               FROM  
>                        T_RES_ZONE ZONE left outer join T_VIEW_PORT2ZONE 
> PORT2ZONE on  
>                        ZONE.ZONE_ID = PORT2ZONE.ZONE_ID   ,  T_RES_FABRIC 
> FABRIC 
> In this query, it is complaining that one of the columns is a VARCHAR and 
> cannot be compared to INTEGER, when clearly this is not the case...
> Same issue

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to