jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (JCR-3261) BundleDbPersistenceManager getAllIds gives wrong amount of results for MySQL
Date Fri, 16 Mar 2012 14:27:41 GMT

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

Unico Hommes updated JCR-3261:

    Attachment: bdbpm_allids.patch

Patch against 2.4.x branch.

The special handling of maxcount is only necessary in the case of longlong storage model.
In the case of a binary storage model I can easily understand that ordering is not well defined
and can vary from database to database. Therefore only do the special handling for longlong
storage model. 
> BundleDbPersistenceManager getAllIds gives wrong amount of results for MySQL
> ----------------------------------------------------------------------------
>                 Key: JCR-3261
>                 URL: https://issues.apache.org/jira/browse/JCR-3261
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>    Affects Versions: 2.4
>            Reporter: Unico Hommes
>             Fix For: 2.4.1
>         Attachments: bdbpm_allids.patch
> The problem arises when the method parameter maxcount is less than the total amount of
records in the bundle table.
> First of all I found out that mysql orders the nodeid objects different than jackrabbit
does. The following test describes this idea:
>     public void testMySQLOrderByNodeId() throws Exception {
>         NodeId nodeId1 = new NodeId("7ff9e87c-f87f-4d35-9d61-2e298e56ac37");
>         NodeId nodeId2 = new NodeId("9fd0d452-b5d0-426b-8a0f-bef830ba0495");
>         PreparedStatement stmt = connection.prepareStatement("SELECT NODE_ID FROM DEFAULT_BUNDLE
>         Object[] params = new Object[] { nodeId1.getRawBytes(), nodeId2.getRawBytes()
>         stmt.setObject(1, params[0]);
>         stmt.setObject(2, params[1]);
>         ArrayList<NodeId> nodeIds = new ArrayList<NodeId>();
>         ResultSet resultSet = stmt.executeQuery();
>         while(resultSet.next()) {
>             NodeId nodeId = new NodeId(resultSet.getBytes(1));
>             System.out.println(nodeId);
>             nodeIds.add(nodeId);
>         }
>         Collections.sort(nodeIds);
>         for (NodeId nodeId : nodeIds) {
>             System.out.println(nodeId);
>         }
>     }
> Which results in the following output:
> 7ff9e87c-f87f-4d35-9d61-2e298e56ac37
> 9fd0d452-b5d0-426b-8a0f-bef830ba0495
> 9fd0d452-b5d0-426b-8a0f-bef830ba0495
> 7ff9e87c-f87f-4d35-9d61-2e298e56ac37
> Now the problem with the getAllNodeIds method is that it fetches an extra 10 records
on top of maxcount (to avoid a problem where the first key is not the one you that is wanted).
Afterwards it skips a number of records again, this time using nodeid.compareto. This compareto
statement returns true unexpectedly for mysql because the code doesn't expect the mysql ordering.
> I had the situation where I had about 17000 records in the bundle table but consecutively
getting the ids a thousand records at a time returned only about 8000 records in all.
> I'll attach a patch that fixes the problem.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message