Clone
 

randall hauch <rhauch@redhat.com> in ModeShape

prepare for next development iteration

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2672 76366958-4244-0410-ad5e-bbfabb93f86b

[maven-release-plugin] prepare for next development iteration

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2671 76366958-4244-0410-ad5e-bbfabb93f86b

    • -1
    • +1
    /extensions/modeshape-clustering/pom.xml
  1. … 36 more files in changeset.
[maven-release-plugin] copy for tag modeshape-2.4.0.Final

git-svn-id: https://svn.jboss.org/repos/modeshape/tags/modeshape-2.4.0.Final@2670 76366958-4244-0410-ad5e-bbfabb93f86b

    • -1
    • +1
    /extensions/modeshape-clustering/pom.xml
  1. … 36 more files in changeset.
[maven-release-plugin] prepare release modeshape-2.4.0.Final

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2669 76366958-4244-0410-ad5e-bbfabb93f86b

    • -1
    • +1
    /extensions/modeshape-clustering/pom.xml
  1. … 36 more files in changeset.
MODE-1066, MODE-1071 Added a new background garbage collection facility to the connector API and ModeShape engine

This new facility includes:

- a new CollectGarbageRequest, with a field allowing the connector to specify whether the garbage collection

operation was completed or whether another pass could/should be made by the requestor

- a default implementation of the RequestProcessor.process(CollectGarbageRequest) that does nothing; existing

connectors by default implement this behavior and don't need to change

- a new field on RepositorySourceCapabilities that allows the connector to express whether it automatically

cleans up unused content (collects garbage), or whether it needs to be done with an explicit CollectGarbageRequest

- a new method on RepositoryService (which owns the library of RepositorySource instances) that will find the

RepositorySource instances that require explicit garbage collection, and upon these (if there are any)

iteratively make the CollectGarbageRequest; the source will be enqueued again if another collection pass is required

- a new background scheduled executor in ModeShapeEngine (the superclass of JcrEngine) to periodically (and

in a background thread) have the RepositoryService collect garbage on its sources.

- a new configuration property that defines the time interval for the periodic, background garbage collection

(the default is every 10 minutes).

Also changed the JPA connector to override the RequestProcessor.process(CollectGarbageRequest) by removing all

unused LargeValueEntity records in all workspaces, and to declare in its RepositorySourceCapabilities that manual

GC is required. Since this is now done explicitly, removing nodes no longer removes unused LargeValueEntity records.

This should improve the performance of certain operations, and because the LargeValueEntity records (keyed by

their SHA-1) stick around for a longer period of time, they remain available to be reused. For example, if repository

content is removed but replaced with mostly similar content, any large values (strings or binary property values)

that are the same actually would be reused.

Also, the MySQL-specific logic for removing LargeValueEntity (see MODE-691) was changed to use a single native SQL

delete statement. This is much more efficient, and on-par with the HQL delete statement used for other Hibernate

dialects. The native MySQL statement was needed because HQL was inadequate for deleting the unused LargeValueEntity

without resorting to a subquery that used the LargeValueEntity table, which is not supported by MySQL. So instead,

the native MySQL delete statement uses a left outer join between the LargeValueEntity and "usages" table and a

criteria on the result to ensure that the only records returned are those without any "usages" records in the

tuples. This works because a left outer join between tables A and B always contains all records from A, whether

or not there are no corresponding records from B. And, if a criteria is added such that a column from B that

can never be null is actually null, then we know the result will contain only those records from A that

do **not** have a corresponding B record. In our case, this ends up deleting only those LargeValueEntity records

that are not referenced in the "usages" table (i.e., they are not used).

Updated a couple of test cases and added a few more that deal with the new feature. A new "mysql5_local" database

configuration was added to the POM, and this required modification of several test cases that depended on the

database configuration name to find files in test data.

All unit and integration tests pass while using HSQLDB and MySQL5.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2668 76366958-4244-0410-ad5e-bbfabb93f86b

  1. … 12 more files in changeset.
MODE-1066 Added several test cases to attempt to replicate the reported problem (without success so far).

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2667 76366958-4244-0410-ad5e-bbfabb93f86b

    • -0
    • +470
    /modeshape-integration-tests/src/test/resources/io/cars-system-view-with-uuids.xml
    • -0
    • +161
    /modeshape-integration-tests/src/test/resources/io/cars-system-view.xml
    • -0
    • +50
    /modeshape-integration-tests/src/test/resources/io/cars.cnd
Correction to the logic in the JDBC driver's POM that removes duplicate files in the META-INF folder. Prior to this fix, the POM was hard-coded to use the 2.2.1 version.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2666 76366958-4244-0410-ad5e-bbfabb93f86b

Corrected JDBC driver project's Maven version number.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2665 76366958-4244-0410-ad5e-bbfabb93f86b

Updated the Reference Guide and Getting Started Guide to reflect the 2.4.0.Final version number and what's new in the 2.4.0.Final release.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2664 76366958-4244-0410-ad5e-bbfabb93f86b

Added Van to the list of developers in the parent POM.

git-svn-id: https://svn.jboss.org/repos/modeshape/branches/2.2.x@2663 76366958-4244-0410-ad5e-bbfabb93f86b

Added Van to the list of developers in the parent POM.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2662 76366958-4244-0410-ad5e-bbfabb93f86b

MODE-1027 Made one additional tweak: if the new content is considered 'mix:versionable', then the RESTful service will do a checkin (which is how the JCR API is used when content is newly marked as versionable).

git-svn-id: https://svn.jboss.org/repos/modeshape/branches/2.2.x@2661 76366958-4244-0410-ad5e-bbfabb93f86b

MODE-1027 Improved the support for publishing versionable files.

Changed the RESTful service to support modifying a subgraph via a PUT. With this change, the same JSON request for a POST (for create) could be sent as a PUT to update the subgraph rather than delete it. Of course, the JSON request only needs to include properties that change, although every child node needs to be specified. The previous PUT JSON request format (containing the properties to change) is still supported and behaves as before. Note that, before updating a node, the RESTful service first checks if the node is 'mix:versionable'. If it is, then the service checks out the node, modifies it, and then checks it back in. If it is not versionable, it just directly modifies the node.

Also changed the REST client to no longer unpublish an existing file before publishing a new one. Instead, if the file is already there, it submits the new file as a PUT rather than a POST.

git-svn-id: https://svn.jboss.org/repos/modeshape/branches/2.2.x@2660 76366958-4244-0410-ad5e-bbfabb93f86b

MODE-1027 Made one additional tweak: if the new content is considered 'mix:versionable', then the RESTful service will do a checkin (which is how the JCR API is used when content is newly marked as versionable).

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2659 76366958-4244-0410-ad5e-bbfabb93f86b

MODE-1027 Improved the support for publishing versionable files.

Changed the RESTful service to support modifying a subgraph via a PUT. With this change, the same JSON request for a POST (for create) could be sent as a PUT to update the subgraph rather than delete it. Of course, the JSON request only needs to include properties that change, although every child node needs to be specified. The previous PUT JSON request format (containing the properties to change) is still supported and behaves as before. Note that, before updating a node, the RESTful service first checks if the node is 'mix:versionable'. If it is, then the service checks out the node, modifies it, and then checks it back in. If it is not versionable, it just directly modifies the node.

Also changed the REST client to no longer unpublish an existing file before publishing a new one. Instead, if the file is already there, it submits the new file as a PUT rather than a POST.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2658 76366958-4244-0410-ad5e-bbfabb93f86b

Added test case that verified the behavior as brought up in a discussion thread.

git-svn-id: https://svn.jboss.org/repos/modeshape/branches/2.2.x@2655 76366958-4244-0410-ad5e-bbfabb93f86b

Added test case that verified the behavior as brought up in a discussion thread.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2654 76366958-4244-0410-ad5e-bbfabb93f86b

MODE-1067 Removed duplicate test and ignored another problematic test.

git-svn-id: https://svn.jboss.org/repos/modeshape/branches/2.2.x@2653 76366958-4244-0410-ad5e-bbfabb93f86b

MODE-1067 Removed duplicate test and ignored another problematic test.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2652 76366958-4244-0410-ad5e-bbfabb93f86b

MODE-1066 Rolling back the correction of a unit test, since the Hudson builds are failing with this change (though this change is required locally).

git-svn-id: https://svn.jboss.org/repos/modeshape/branches/2.2.x@2651 76366958-4244-0410-ad5e-bbfabb93f86b

MODE-1066 Rolling back the correction of a unit test, since the Hudson builds are failing with this change (though this change is required locally).

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2650 76366958-4244-0410-ad5e-bbfabb93f86b

MODE-1067 The code contained three ways in which nodes were retrieved while processing the results of a query. One of these properly handled the case where the node was deleted in persistent storage, but was returned in the query result tuples because the indexes weren't yet updated to reflect the deletion. The two other ways were not handling this case, so these were corrected.

All unit and integration tests pass with these changes.

git-svn-id: https://svn.jboss.org/repos/modeshape/branches/2.2.x@2649 76366958-4244-0410-ad5e-bbfabb93f86b

MODE-1067 The code contained three ways in which nodes were retrieved while processing the results of a query. One of these properly handled the case where the node was deleted in persistent storage, but was returned in the query result tuples because the indexes weren't yet updated to reflect the deletion. The two other ways were not handling this case, so these were corrected.

All unit and integration tests pass with these changes.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2648 76366958-4244-0410-ad5e-bbfabb93f86b

MODE-1049 Corrected four more unit tests that were failing due to recent changes with ISDESCENDANTNODE criteria.

git-svn-id: https://svn.jboss.org/repos/modeshape/branches/2.2.x@2643 76366958-4244-0410-ad5e-bbfabb93f86b

MODE-1049 Corrected four more unit tests that were failing due to recent changes with ISDESCENDANTNODE criteria.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2642 76366958-4244-0410-ad5e-bbfabb93f86b

MODE-1049 Corrected one of the test cases (and added another) that deals with ISDESCENDANTNODE criteria. The expected results were incorrect.

git-svn-id: https://svn.jboss.org/repos/modeshape/branches/2.2.x@2641 76366958-4244-0410-ad5e-bbfabb93f86b

MODE-1052 Corrected the logic in the LuceneSearchEngine for handling NOT criteria.

git-svn-id: https://svn.jboss.org/repos/modeshape/branches/2.2.x@2640 76366958-4244-0410-ad5e-bbfabb93f86b

MODE-1049 Corrected one of the test cases (and added another) that deals with ISDESCENDANTNODE criteria. The expected results were incorrect.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2639 76366958-4244-0410-ad5e-bbfabb93f86b

MODE-1052 Corrected the logic in the LuceneSearchEngine for handling NOT criteria.

git-svn-id: https://svn.jboss.org/repos/modeshape/trunk@2638 76366958-4244-0410-ad5e-bbfabb93f86b

MODE-1049 Corrected the PlanUtil.replaceViewReferences(...) method, which was returning a ChildNodeJoinCondition when it should be returning a DescendantNodeJoinCondition instance. All unit and integration tests pass with this correction.

git-svn-id: https://svn.jboss.org/repos/modeshape/branches/2.2.x@2637 76366958-4244-0410-ad5e-bbfabb93f86b