Clone Tools
  • last updated a few minutes ago
Constraints: committers
Constraints: files
Constraints: dates
MODE-2313 Corrected concurrent modification exceptions, and changed query engine to not use indexes that are being rebuild via re-indexing.

  1. … 9 more files in changeset.
MODE-2307 Indexes are now used when join conditions can be applied

Previously, index applicability only took into account constraints. So when an access query did not have any constraints (other than on jcr:primaryType or jcr:mixinTypes) then indexes were not considered, even though an index might apply to one of the selectors & properties on one side of the join condition.

With this change, it is now possible for the repository to try to apply indexes based upon constraints and/or join conditions. For example, an index on 'jcr:uuid' might apply to a SameNodeJoinCondition. Or, a property index might apply when an EquiJoinCondition involves that property.

Note that in these cases, join conditions have no literal values on which the index can filter its results, but it still can be used by returning all nodes in the index. This still might be significantly better than scanning the index.

It's even possible now that indexes might be applied based upon join constraints (additional constraints that apply to the join, and that cannot be pushed down to either side of the join).

  1. … 6 more files in changeset.
MODE-2301 Added support for indexes to be updated synchronously or asynchronously

Prior to this commit, all updates to the indexes in the 4.0 codebase were asynchronous. That means that

the method added the ChangeSet describing the session's changes onto the event bus and

then returned. All index updates were done in separate listener threads on the event bus, so it's entirely

possible (and perhaps likely) that any updates to the indexes happen after the client's call to

returned. The net effect is that the client might make changes and immediately issue a query that would not

find the recently-saved changes. Additionally, there was no way for the client to know when the indexes would

be updated.

With this commit, it is possible to define whether each index is updated synchronously before the

the returns, or asynchronously so that index updates are made in a separate thread.

This commit changes the default behavior of the index updates to be *synchronous*.

In a cluster, any changes made on one process are sent via the change bus to the other processes,

and the indexes in those other processes are always updated asynchronously. In other words, if an

index provider keeps copies of the indexes on every process, then only the local indexes are updated

synchronously before save returns -- and that does not wait until the indexes in the other

processes are updated.

In order to properly implement this, a small change was made to the ChangeBus to expand the semantic concept

of an "in-thread" listener. Prior to this, "in-thread" meant that the listener only received locally-originating

change sets. Now, it's still possible to do this (and the journal uses this older behavior), but it's also

possible to register a listener such that locally-originating change sets are handled in-thread while remotely

originating change sets are handled asynchronously.

  1. … 20 more files in changeset.
MODE-2295 Fixed a number of issues with indexes

Indexes were not properly removing values, nor were they adding only nodes that satisfied their

definition's node type. Correcting the latter required handling when the node types in the repository

were changed, which might affect which node types are to be included in a given index. Therefore,

care was taken so that the index provider implementations' IndexChangeAdapters automatically handled

changes in the repository's node types.

A number of tests were added to replicate the problems reported in MODE-2295, and even more were

added to verify the proper behavior (including removing values) in the low-level local index

implementations. In particular, the UniqueKeyComparator logic was not quite handling all of the negative

infinity cases it should have (it was already correctly handling the positive infinity cases).

    • -10
    • +14
    • -16
    • +114
    • -0
    • +130
  1. … 23 more files in changeset.
MODE-2285 More correctios to the index provider behavior in the Wildfly subsystem.

After these changes, any index provider or index definitions in the subsystem XML remain there and unmodified even after shutdown.

The problem was the 'relative-to' and 'path' index provider properties were not in the list of model attributes, and thus ignored

(in some scenarios only).

Also fixed a potential NPE in the IndexProvider base class.

  1. … 5 more files in changeset.
MODE-2292 Indexes and definitions are now properly persisted and work across repository restarts.

  1. … 17 more files in changeset.
Merge pull request #1230 from rhauch/mode-2151

MODE-2151 Added support for CHILDCOUNT dynamic operand and the 'mode:childCount' pseudocolumn

MODE-2151 Added support for CHILDCOUNT dynamic operand

Pretty basic support that should prove quite useful in certain situations. This may be relatively

expensive when the repository has nodes with lots of children since it requires loading the parent

node's child references in order to obtain the count. The CHILDCOUNT criteria would therefore work

much better/faster as filtering criteria in a query that already defines criteria that indexes can


  1. … 17 more files in changeset.
MODE-2290 Corrected use of indexes for criteria with aliases and bind variables

Corrected the way that indexes are planned for criteria that involve aliases and bind variables. Also added several new tests to verify the expected behavior.

  1. … 9 more files in changeset.
MODE-2160 Incorporated recent comments and added validation of IndexDefinintions before registration.

  1. … 8 more files in changeset.
MODE-2160 Completed the first stab at a local index provider. There are only a few very limited test cases, but they do pass and show that the provider is able to be included in the query plan, properly selected for use, and properly used during query execution.

    • -0
    • +35
    • -96
    • +330
    • -0
    • +280
  1. … 52 more files in changeset.
MODE-2160 Refactored the query engine and index provider SPI.

Changed how index providers are initialized, changed the indexing to use only events, changed the reindexing mechanism to use a much simplified IndexWriter, and added a partial LocalIndex and provider implementation (still needs work).

    • -52
    • +0
    • -65
    • +0
    • -0
    • +456
    • -0
    • +70
    • -0
    • +47
    • -0
    • +51
  1. … 101 more files in changeset.
MODE-2188 Added management of index providers to Wildfly subsystem

It is now possible to manage the index providers using the Wildfly configuration and CLI tools.

Additionally, ModeShape is no longer dependent upon Lucene or Hibernate Search.

  1. … 138 more files in changeset.
MODE-2188 Added management of index providers and index definitions

ModeShape now can manage index providers and index definitions via a programmatic API

that allows registering new/updated providers and adding/updating/removing index definitions.

Index definitions are stored as nodes in the system area using a structure such as


Changes on one process in the cluster will be persisted to the cace store, and events

on all processes in the cluster will signal a refreshing of a snapshot of the index

definitions used by the query system. Additionally, when changes are made to

an index definition, the provider that owns that definition will be notified of the

new/changed or removed index definition.

Index provider information is not stored in the system area, but rather is used to

instantiate the providers in the same way as sequencers and connectors. Thus,

the repository configuration for each process in the cluster needs to define the

index providers; no information is shared across processes. Notice that all process-specific

information about indexes must be defined on the provider. For example, a notional

provider that stores indexes on the file system would likely require as a configuration

setting the directory in which those files are stored, and this could vary in each

process' configuration. BTW, this maintains ModeShape's convention of using the same

repository configuration file on each process in the cluster, albeit with variables

for any configuration parameters that must vary for the different processes.

Every index definition explicitly states the name of the provider that owns it.

If there is no such provider, ModeShape will mark the index definition as 'disabled'

and it will not be used on that process.

At this time it is not yet possible to define index providers or index definitions

in the repository configuration JSON file or the Wildfly subsystem. This will be

done with a future commit.

However, it is possible with this commit to programmatically register a provider

and define multiple indexes. Testing will also be done in a future commit as a

practical and usable provider is available.

The package and most of the interfaces in the index SPI introduced in 4.0.0.Alpha1

(e.g., formerly 'org.modeshape.jcr.spi.query') were renamed to be shorter and

more appropriate for their current & planned scope. For example, the "QueryIndexProvider"

interface is now simply "IndexProvider".

    • -0
    • +44
    • -0
    • +52
    • -0
    • +107
    • -0
    • +43
    • -0
    • +93
    • -0
    • +65
    • -0
    • +124
    • -0
    • +65
    • -0
    • +65
    • -0
    • +104
    • -0
    • +58
  1. … 58 more files in changeset.