db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dyre.Tjeldv...@Sun.COM
Subject Re: Generate Always and SQLIntegrityConstraintViolationException
Date Tue, 22 Jan 2008 18:02:34 GMT
Daniel John Debrunner <djd@apache.org> writes:

> Dyre.Tjeldvoll@Sun.COM wrote:
>> Daniel John Debrunner <djd@apache.org> writes: 
>>> I think the real bug is that canCacheRow is being passed in as true
>>> for the row of (default) when it should be false if the default column
>>> definition does not translate to a constant over time. 
>> So the compiler actually generates incorrect parameters for the
>> RowResultSet constructor in this case?
> That's my guess.

Good guess :) 

I've traced it to RowResultSetNode.canWeCacheResults() (no
big surprise) which returns false in the CURRENT_TIMESTAMP case, and
true in the identity case.

canWeCacheResults() use a rather tricky visitor pattern, but I think it
ends up returning true because the ResultColumn.expression points to a
NumericConstantNode, and NumericConstantNode.getOrderableVariantType()
(actually inherited from ConstantNode) 
returns Qualifier.CONSTANT.

CurrentDatetimeOperatorNode.getOrderableVariantType() on the other hand
returns Qualifier.QUERY_INVARIANT, which is then transformed to
Qualifier.SCAN_INVARIANT in ResultColumn.getOrderableVariantType().

Not sure where the default identity information should be detected in
all of this though...


View raw message