[Java DB - testing] Error continuous trunk (rev 1817002)

[ingemar . aberg]

Java DB testing and reporting infrastructure.

Error continuous trunk (rev 1817002)

There were execution errors and/or timeouts.

Jenkins build is back to stable : Derby-trunk-suites.All #135

[Apache Jenkins Server]

See 

[jira] [Commented] (DERBY-6945) Re-package Derby as a collection of jigsaw modules

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16275778#comment-16275778
 ] 

ASF subversion and git services commented on DERBY-6945:


Commit 1817002 from [~rhillegas] in branch 'code/trunk'
[ https://svn.apache.org/r1817002 ]

DERBY-6945: Remove dependency of proposed modules on derbyPreBuild; commit 
derby-6945-01-aa-remove_derbyPreBuild_dep.diff.

> Re-package Derby as a collection of jigsaw modules
> --
>
> Key: DERBY-6945
> URL: https://issues.apache.org/jira/browse/DERBY-6945
> Project: Derby
>  Issue Type: Improvement
>Affects Versions: 10.13.1.2
>Reporter: Rick Hillegas
> Attachments: derby-6945-01-aa-remove_derbyPreBuild_dep.diff, 
> jdeps.out.tar
>
>
> Once we commit to building with Java 9 (see DERBY-6856), we should consider 
> re-packaging Derby as a set of jigsaw modules. This would result in a 
> different set of release artifacts. This might be a good opportunity to 
> address the Tomcat artifactory issues raised by issue DERBY-6944.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DERBY-6945) Re-package Derby as a collection of jigsaw modules

[Rick Hillegas (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16275776#comment-16275776
 ] 

Rick Hillegas commented on DERBY-6945:
--

Tests passed cleanly on derby-6945-01-aa-remove_derbyPreBuild_dep.diff.

> Re-package Derby as a collection of jigsaw modules
> --
>
> Key: DERBY-6945
> URL: https://issues.apache.org/jira/browse/DERBY-6945
> Project: Derby
>  Issue Type: Improvement
>Affects Versions: 10.13.1.2
>Reporter: Rick Hillegas
> Attachments: derby-6945-01-aa-remove_derbyPreBuild_dep.diff, 
> jdeps.out.tar
>
>
> Once we commit to building with Java 9 (see DERBY-6856), we should consider 
> re-packaging Derby as a set of jigsaw modules. This would result in a 
> different set of release artifacts. This might be a good opportunity to 
> address the Tomcat artifactory issues raised by issue DERBY-6944.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (DERBY-6945) Re-package Derby as a collection of jigsaw modules

[Rick Hillegas (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rick Hillegas updated DERBY-6945:
-
Attachment: derby-6945-01-aa-remove_derbyPreBuild_dep.diff

Attaching derby-6945-01-aa-remove_derbyPreBuild_dep.diff. This patch moves the 
declaration of a constant out the derbyPreBuild package and into one of the 
services packages. This causes compiled product files to no longer reference 
the derbyPreBuild package. That, in turn, removes derbyPreBuild from the jdeps 
graph of module dependencies. I will run tests.

Touches the following files:



M   
java/engine/org/apache/derby/iapi/services/info/ProductVersionHolder.java
M   java/engine/org/apache/derby/iapi/services/info/PropertyNames.java

Move the constant into PropertyNames.



M   java/build/org/apache/derbyPreBuild/ReleaseProperties.java
M   java/build/org/apache/derbyPreBuild/build.xml

Move the constant out of ReleaseProperties and adjust the pre-build so that the 
PropertyNames are comiled along with the derbyPreBuild package.


> Re-package Derby as a collection of jigsaw modules
> --
>
> Key: DERBY-6945
> URL: https://issues.apache.org/jira/browse/DERBY-6945
> Project: Derby
>  Issue Type: Improvement
>Affects Versions: 10.13.1.2
>Reporter: Rick Hillegas
> Attachments: derby-6945-01-aa-remove_derbyPreBuild_dep.diff, 
> jdeps.out.tar
>
>
> Once we commit to building with Java 9 (see DERBY-6856), we should consider 
> re-packaging Derby as a set of jigsaw modules. This would result in a 
> different set of release artifacts. This might be a good opportunity to 
> address the Tomcat artifactory issues raised by issue DERBY-6944.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DERBY-6978) Select for ID does not deliver existing Row

[Rick Hillegas (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16275652#comment-16275652
 ] 

Rick Hillegas commented on DERBY-6978:
--

Hi Christian,

I can confirm that you are not going crazy. Your database is certainly messed 
up.

{noformat}
select count(*) from treeentry;
{noformat}

returns 1426 as the number of rows in the table. That is, until I drop all the 
constraints on the table. Then the query returns 1492 as expected. It looks 
like the constraint indexes are corrupt. I don't know how they were broken. Do 
you remember what you were doing when the indexes broke?

Who knows what else is corrupt. I recommend that you siphon the data out of the 
old database into a new one and then abandon the corrupt database. Fortunately, 
you can salvage the database as follows: 

1) Rename savdb to oldsavdb.

2) Run the following script:

{noformat}
connect 'jdbc:derby:savdb;create=true';

call syscs_util.syscs_register_tool( 'foreignViews', true, 
'jdbc:derby:oldsavdb', 'XYZ_' );

create table treeentry as select * from xyz_app.treeentry with no data;

insert into treeentry select * from xyz_app.treeentry;

call syscs_util.syscs_register_tool( 'foreignViews', false, 
'jdbc:derby:oldsavdb', 'XYZ_' );
{noformat}

3) Then add your constraints back onto the table. Alternatively, you can create 
savdb using your original DDL and then siphon the old data into it by using the 
foreignViews optional tool as sketched above. The foreignViews tool is 
documented in the Tools Guide at 
http://db.apache.org/derby/docs/10.14/tools/index.html.

Hope this helps,
-Rick


> Select for ID does not deliver existing Row
> ---
>
> Key: DERBY-6978
> URL: https://issues.apache.org/jira/browse/DERBY-6978
> Project: Derby
>  Issue Type: Bug
>Reporter: Christian Lutz
> Attachments: 20173011_derbydb_bugreport.zip
>
>
> Hello everybody,
> we are currently facing a rather strange problem, using the Derby-DB.
> In the attached Database there is one table left, called 'TreeEntry' and for 
> several kinds of querries performed on it Derby claims something different 
> than is actually true.
> For example the statement
> {code}
> select count(*) from treeentry;
> {code}
> tells, that there would be 1426 lines in the table, but if I select all rows 
> and copy them into an editor I see, that there are actually 1492 lines.
> Furthermore, the following statement actually returns data, which, in my 
> understanding, should never be the case:
> {code}
> select * from treeentry t where id not in (select id from treeentry where id 
> = t.id);
> {code}
> But on the other hand 
> {code}
> select count(*) from treeentry t where id not in (select id from treeentry 
> where id = t.id);
> {code}
> tells, that there would be zero such rows.
> In the result of the beforementioned select I see, that a line exists, that 
> has the ID 111664.
> If I then explicitly select for this row (which I've just seen existing in 
> the previous select) via
> {code}
> select * from treeentry where id = 111664;
> {code}
> nothing is returned.
> I tried updating the statistics for this table via
> {code}
> CALL SYSCS_UTIL.SYSCS_UPDATE_STATISTICS('APP', 'TREEENTRY', null)
> {code}
> but this call does not terminate.
> But here I have to remark, that there were also several other tables in the 
> database with the same phenomenon existing, where this call actually 
> terminated, even though it didn't change anything about the problem.
> The derby version, with which this problem appeared was 10.12.1.1
> But unfortunately, I have absolutely no idea of how to reproduce it.
> The only thing I probably can say, that has been done before this issue 
> appeared, was, that the database was copied from one system to another. I 
> don't expect any kinds of incompatibilities there, as, after we discovered 
> this issue, we did the same with a backup of the database in the same way and 
> the issue did not reappear.
> I would be very happy, if someone could give me some kind of hint about 
> whether this is a known and already fixed problem, what we could maybe do to 
> avoid this in the future or similar.
> User and Password for the attached Database are btw APP/APP.
> If you need any further information from me I'm glad to deliver this still.
> Thank you already for your help.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)