db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Solberg <Ole.Solb...@Sun.COM>
Subject Re: Failure in lang/compressTable.sql with current 10.3 branch
Date Thu, 22 Nov 2007 22:43:00 GMT
Henri van de Scheur wrote:
> Hi Bryan!
> 
> I also see it in my daily tests on 10.3. Look for instance at 
> http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.4/FailReports/596747_bySig.html 
> 
> It started to appear the 20th of November, so that might help?
> It appears on all platforms and under all jvm-versions.
> (see http://dbtg.thresher.com/derby/test/ - 10.3 Branch - daily)
> 
> Henri
> 
> Bryan Pendleton wrote:
> 
>> Hi all,
>>
>> I'm seeing a failure in lang/compressTable.sql with the current 10.3 
>> branch.
>> Is anyone else seeing this?
>>
>> The diff appears to involve a slight difference in the value of the last
>> column in the SYS.SYSSTATISTICS catalog.
>>
>> Here's a snip from compressTable.tmpmstr:
>>
>> create index t2i1 on derby737table2(c1);
>> 0 rows inserted/updated/deleted
>> ij> select * from sys.sysstatistics;
>> STATID                              
>> |REFERENCEID                         |TABLEID           
>> |CREATIONTIMESTAMP         |&|VALID|COLCOUNT   |STATISTICS
>> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------

>>
>> xxxxFILTERED-UUIDxxxx|xxxxFILTERED-UUIDxxxx|xxxxFILTERED-UUIDxxxx|xxxxxxFILTERED-TIMESTAMPxxxxx|I|true

>> |1          |numunique= &
>>
>> And here's the equivalent section of my compressTable.out:
>>
>> create index t2i1 on derby737table2(c1);
>> 0 rows inserted/updated/deleted
>> ij> select * from sys.sysstatistics;
>> STATID                              
>> |REFERENCEID                         |TABLEID           
>> |CREATIONTIMESTAMP         |&|VALID|COLCOUNT   |STATISTICS
>> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

>>
>> xxxxFILTERED-UUIDxxxx|xxxxFILTERED-UUIDxxxx|xxxxFILTERED-UUIDxxxx|xxxxxxFILTERED-TIMESTAMPxxxxx|I|true

>> |1          |numunique= 2 n&
>>
>> This diff appears to occur in all the SYS.SYSSTATISTICS references in
>> the DERBY-737 section of compressTable.sql.
>>
>> Does anyone have a suggestion as to what might be causing this?
>>
>> thanks,
>>
>> bryan
>>


I guess r566353 needs to be backported to 10.3 as well:



11/21/2007 09:11 AM Ole Solberg (JIRA) wrote:
 >     [ 
https://issues.apache.org/jira/browse/DERBY-1734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544189

]
 >
 > Ole Solberg commented on DERBY-1734:
 > ------------------------------------
 >
 > 2007-11-20 nightlies: 10.3 regression tests fails in 
lang/CompressTable.sql.
 >
 > Probably caused by r596490 which includes r564792:
 >
 > We saw the same with r564792 on trunk. This was fixed by
 > r566353 | djd | 2007-08-15 23:45:33 +0200 (Wed, 15 Aug 2007) | 1 line 
- Fix compressTable master file.
 >
 > See e.g. 
http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.6/testing/Limited/testSummary-596747.html
 > or http://dbtg.thresher.com/derby/test/stats_today.html as of 
2007-11-21 (the "-5001" entry).
 >
 >
 >
 >
 >>Simplify building of SystemColumn array in CatalogRowFactory 
implementations.
 >>------------------------------------------------------------------------------
 >>
 >>                Key: DERBY-1734
 >>                URL: https://issues.apache.org/jira/browse/DERBY-1734
 >>            Project: Derby
 >>         Issue Type: Sub-task
 >>         Components: SQL
 >>           Reporter: Daniel John Debrunner
 >>           Assignee: Daniel John Debrunner
 >>           Priority: Minor
 >>            Fix For: 10.4.0.0
 >>
 >>
 >>The implementations of CatalogRowFactory.buildColumnList() can be 
simplified in a number of ways:
 >>  1) precision & scale are always passed in as zero and can be removed
 >>   2) adding static factory methods to SystemColumnImpl would ease 
the building of the arrays by not requiring the additional redundant 
arguments the constructor call forces today, e.g. max length i snot 
required to create an INTEGER column.
 >>    3) The column's position is not required to be stored in the 
SytstemColumn class, it's defined by the position in the array
 >>4) arrays can be built using
 >>          new SystemColumn[] { ... }
 >>     syntax instead of the existing
 >>            columnList[0] = ...
 >>            columnList[1] = ...
 >>      or
 >>            columnList[index++] = ...
 >>            columnList[index++] = ...
 >>
 >
 >
-- 
Ole Solberg, Database Technology Group,
Sun Microsystems, Trondheim, Norway

Mime
View raw message