Clone Tools
  • last updated a few minutes ago
Constraints: committers
Constraints: files
Constraints: dates
MODE-2522 Removes the Joda date-time library dependency and switches to javax.time This also changes the current ModeShape DateTime API removing a lot of the existing methods and encouraging users to use the standard JDK 1.8 API.

  1. … 28 more files in changeset.
MODE-2516 Updates JDK to 1.8 and jboss-parent to the latest version (19) This is the first significant commit of the 5.x series and contains a number of significant changes: - the naming of Maven version properties changed to adopt the standard pattern: 'version.<groupId>.<artifactId>' - build system and dependency updates so that the latest Maven plugin versions function correctly - updating source code to avoid compiler and javadoc warnings

    • -1
    • +3
  1. … 153 more files in changeset.
MODE-2299 Suppressed several compiler warnings about use of deprecated APIs from the recently-updated Apache HttpClient library.

  1. … 2 more files in changeset.
MODE-2185 Fixed JavaDoc error and Java compiler warnings

  1. … 7 more files in changeset.
MODE-2185 Removed the ModeShape REST client (modeshape-web-jcr-rest-client module). The functionality required by the remote JDBC Driver was moved to the modeshape-jdbc package and a new, lightweight client created which only performs the functionality required by the driver.

    • -0
    • +2
    • -0
    • +171
    • -0
    • +75
    • -0
    • +93
    • -0
    • +250
    • -0
    • +174
    • -0
    • +419
    • -0
    • +90
    • -0
    • +410
    • -0
    • +133
    • -0
    • +161
    • -0
    • +68
  1. … 66 more files in changeset.
MODE-2184 Added a public 'close' method to QueryResult public API.

  1. … 3 more files in changeset.
MODE-2018 Implemented new query engine.

Refactored the query functionality to now use several new service provider interfaces (SPI),

and implemented a new query engine that can take advantage of administrator-defined indexes.

When no such indexes are defined, the query engine is able to still answer the queries

by "scanning" all nodes in the repository. This is like a regular relational database:

all query functionality works (albeith slowly) even when no indexes are defined, though

to improve performance simply define an appropriate index based upon the query or queries

that are being used.

All of ModeShape's query parsing, planning, and optimization steps are basically unchanged

from the previous query system. There is one addition to the rule-based optimizer: a new

rule looks at query plans and adds the potential indexes that might be of use in each

access query portion of a query plan. Then, the query execution process (see below)

chooses one of the identified indexes based upon the selectivity and cardinality. If no index

is available for that portion of the query plan, then the query engine simply iterates

over all queryable nodes in the repository.

A new kind of component, called a "query index provider", allows the query engine to delegate

various responsibilities around indexes to these providers. For example, a provider must

provide an index planner that can examine the constraints that apply to an access query

and determine if any of the provider's indexes can be used. When they are, ModeShape

adds those indexes to the query plan. If the query engine uses one of those indexes,

then provider must be able to return all of those nodes that satisfy the criteria

as described earlier by its index planner. Finally, as ModeShape content changes, ModeShape

will notify the index providers' of the changes so that they can ensure their indexes

are kept up-to-date with the content.

This means that a provider can implement the functionality using any kind of technology,

and consequently, that ModeShape can begin to leverage multiple kinds of search and index

technology within its query system. The ModeShape community anticipates having providers

that use Lucene, Solr, and ElasticSearch. ModeShape will also likely come with a provider

that maintains file-system based indexes. Additionally, providers can optionally support

indexes on one or more properties. Thus, it will be possible to mix and match

these providers, selecting the best technology for the specific kind of index.

The new query engine does the execution in a very different way than the previous engine,

which used Lucene to determine the tuples (that is, the values in each row) for each access

query and that were then further processed and combined to form the tuples that were returned

in the result set. The new engine instead uses a new concept of a "stream of node keys"

for each access query: what actually implements that stream depends on many factors.

A node sequence is an abstraction of a stream of "rows" containing one or more node keys.

The interfaces are designed to make it possibly to lazily implement a stream in a very

efficient manner. Specifically, a node stream is actually comprised of multiple "batches"

of rows, and batches can be of any size.

Consider when the engine findes no indexes are available for a certain access query. The

engine simply uses a "node sequence" (or NodeSequence) implementation that returns in batches

a row for each node in the repository.

But if an access query involves a criteria on the path of a node, such as

"... WHERE ISSAMENODE('/foo/bar') ...", then ModeShape knows that this query (or portion of

a query) will have only one result, namely the node at "/foo/bar". ModeShape doesn't need

an index to quickly find this node; it merely has to navigate to that path to find the one

node that satisfies this query. ModeShape has several other optimizations, too: it knows

when a query involves all children or descendants of a node at a given path, and can take

this into account when optimizing and executing the query. All of these are handled with

special NodeSequence implementations optimized for each case.

For many access queries (i.e., part of a larger query), the engine will use one of the

indexes identified by one of the providers. When this happens, ModeShape uses other

NodeSequence implementations that utilize the underlying indexes to find the nodes that satisfy

some of the criteria.

The above describes how the engine uses a single NodeSequence instance for each each access

query in a larger query. But how does the engine combine these to determine the ultimate

query results? Basically, the engine constructs a series of functions that process one or more

NodeSequence instances to filter and combine into other NodeSequences.

For example, a custom index might be used to find all nodes that have a 'jcr:lastModified'

timestamp within some range. Presumably this index is used because it has a higher selectivity,

meaning that it will filter out more nodes and return fewer nodes than other indexes.

Other criteria that are also applied to this access query might then be applied by a filter

that processes the actual nodes' property values.

While the result of this commit is a functioning query engine that is shown to work in most

of the query-related unit and integration tests, there still are a few areas that are not complete.


* The new engine does not support full-text search, and currently throws an exception

* No index providers are implemented. Therefore, all queries involve "scanning" the repository.

This can be time consuming, especially for federated repositories. Consequently, all such

tests that query federated content have been disabled/ignored.

  1. … 231 more files in changeset.
MODE-2148 Added checkstyle to our build, and corrected numerous potential problems or issues in the code. Also removed lots of meaningless JavaDoc

    • -0
    • +4
  1. … 366 more files in changeset.
MODE-2081 Changed the license for ModeShape code to ASL 2.0.

    • -18
    • +10
    • -17
    • +9
  1. … 556 more files in changeset.
MODE-2003 Added no-arg constructor back to JcrDriver

    • -0
    • +7
MODE-1901 Added support for obtaining the query plan without executing the query

There is a new 'explain' method in the ModeShape public query API that returns the internal

query plan for a given statement and language. This same functionality

is also exposed in the JDBC driver (as a custom method) and the RESTful

API (v2).

  1. … 23 more files in changeset.
MODE-1888 Added warnings to queries

The ModeShape-specific query API not includes warnings on QueryResult objects. ModeShape will include warnings in a number of cases, including when column names are misspelled (via common patterns), or when columns is a better match with a different selector.

Several new test cases were added to verify the behavior.

  1. … 9 more files in changeset.
MODE-1755 Implemented 'getPlan' in other implementation classes

  1. … 1 more file in changeset.
MODE-1646 Changed the Server object in the REST client to know whether it's validated

The REST client's Server object was changed to know about the validated and original URLs, and

whether it was validated. This will make it easier for applications using the client to know

more about the Server's state and make it easier to track the original URL.

  1. … 2 more files in changeset.
MODE-1646 REST client can now be used to talk to 3.x and 2.x servers

Because of the improvements/changes in the RESTful API in 3.0, using the REST client required using slightly

different URLs to talk to 3.x vs 2.x servers. The reason is that the REST client still uses the older REST API,

and the URL for the older API is different on 3.x servers.

Although it was not feasible to transparently and automatically discover the correct URL given the actual server

the client talks to, it was possible to add a new method that does this. There is now a "validate(Server):Server"

method on the IRestClient interface, and this method can be used to validate a Server instance with a normal

URL (that is, excluding the API version qualifier) based upon the actual server. The method returns a new

Server instance that should be used for all subsequent communications.

Note that clients that don't take advantage of this new method can still work, as long as the URL ends with "/v1" for

3.x servers.

  1. … 5 more files in changeset.
Corrected compiler and JavaDoc warnings.

  1. … 23 more files in changeset.
MODE-872 - Added an Arquillian test for the JDBC remote driver which basically runs the same tests as the driver's integration tests, only against an Arguillian managed AS7 instance, with the ModeShape kit deployed

  1. … 4 more files in changeset.
MODE-872 - Implemented query results translation from the REST client to the remote JDBC driver

In addition:

- cleaned up a bit (only the surface) the code throughout the jdbc-local and jdbc modules

- integrated the -jdbc module with Cargo, so that unit tests containing Http are run in a real container and a remote repository, during the integration phase

    • -10
    • +1
    • -0
    • +204
  1. … 22 more files in changeset.
MODE-872 - Added back into build cycle & fixed tests for the modeshape-jdbc module

The existing tests only test the local driver functionality (JNDI)

  1. … 7 more files in changeset.
MODE-872 - Added back into build cycle & fixed tests for web-jcr-rest-client module.

The following were updated

- cargo plugin version and general cargo usage has been refactored: the parent pom defines & configures the default cargo plugin while the child modules only use that configuration

- the cargo plugin & configuration have been updated to work with the latest version of the plugin & Jetty has been upgraded to 7x

- the JcrResources web service, on the @Delete method, does not need the @Consumed annotation

    • -6
    • +2
  1. … 21 more files in changeset.
Corrected formatting/compiler warnings

    • -1
    • +0
  1. … 35 more files in changeset.
MODE-1472 - Removed SLF4J from the modeshape-client.jar - unnecessary dependencies to slf4j have been removed - the LogFactory from common searches for SFL4j's API in the classpath prior to defaulting to java.util

    • -1
    • +1
  1. … 7 more files in changeset.
MODE-1434 Added support for discovering JDBC drivers with Java service provider mechanism

A 'META-INF/services/java.sql.Driver' file was added to each of our JDBC driver implementations, and the JAR files

were verified to contain these new files.

    • -0
    • +1
  1. … 1 more file in changeset.
MODE-1368 Removed all legacy modules no longer needed in 3.x

ModeShape 3.x will not need a number of the 2.x modules. In particular:

- since 3.x will only have an AS7 kit, the AS5 or AS6 artifacts were removed

- all the connectors were removed, since they're no longer used

- the connector benchmark tests module was removed, replaced by our new

performance test suite

- the JPA DDL generator utility has been removed

- the 'modeshape-graph', 'modeshape-repository', 'modeshape-search-lucene'

and 'modeshape-clustering' modules have all been removed, since the new

'modeshape-jcr' module no longer uses them

- the DocBook modules were removed and are replaced by the Confluence space

- the two JDBC modules were moved out of the 'utils' directory to top-level modules

The build still works, but not all components have been included in the build.

This is because the query functionality doesn't yet work, so quite a few web

and JDBC driver modules all depend on this.

The assembly profile has not yet been changed or corrected.

    • -0
    • +0
    • -0
    • +0
  1. … 3650 more files in changeset.