Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
MODE-2666 Fixes the issue of the Comparators used for MapDB storage not being Serializable This commit also makes sure that when ORDER BY is used with the same column multiple times, only one occurrence is present in the query plan

  1. … 2 more files in changeset.
MODE-2166 Adds CAST dynamic operand for JCR-SQL2.

  1. … 12 more files in changeset.
MODE-2329 Fixed the handling of expanded form selector names for the query engine.

  1. … 2 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. … 7 more files in changeset.
MODE-2297 Corrected asymmetric set operations

A recent change introduced a bug that caused some parts of joins to be removed when rewritten.

  1. … 10 more files in changeset.
MODE-2297 Corrected removal of unused identity joins.

  1. … 8 more files in changeset.
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

use.

  1. … 17 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.

  1. … 59 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).

  1. … 115 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.

Specifically:

* 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. … 228 more files in changeset.
MODE-2081 Changed the remaining files over to the ASL 2.0 license

  1. … 1044 more files in changeset.
MODE-2041 Corrected numerous compiler warninings, JavaDoc errors and warnings, and removed quite a few JavaDoc comments that are inherited via @Override.

  1. … 79 more files in changeset.
MODE-2095 Fixed NPE when executing date range queries.

  1. … 3 more files in changeset.
MODE-2062 Corrected full text search with a bind variable for expression

  1. … 2 more files in changeset.
MODE-2037: Extended like operation (reverse like implementation)

Added a reverse like (e.g., "RELIKE") constraint that is useful when

the LIKE pattern is stored in a node property and the intent is to

find all nodes that have a pattern that matches a given string:

SELECT *

FROM [service:Locator] AS locator

WHERE relike($phone, locator.[service:phonePattern])

  1. … 15 more files in changeset.
MODE-1920 Corrected compiler warnings and JavaDoc errors

  1. … 26 more files in changeset.
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-1865 Additional changes and fixes

The test case added in previous commits (for this issue) was not cleaning

up the 300 nodes it was creating and using for the queries, thus causing

failures in many subsequent tests. This was corrected, and the test case

simplified. The changes to QueryProcessor were also incomplete and did

not always return just one row when using "LIMIT 1", so this was corrected.

  1. … 2 more files in changeset.
MODE-1833 - JQOM Wildcard Query fails with Column 'null' does not exist on the table

Fixed with testcase.

  1. … 3 more files in changeset.
MODE-1825 Added testcase and fix for handling QOM queries where both the columnName and propertyName are null.

  1. … 1 more file in changeset.
MODE-1825 Added testcase and fix for handling QOM queries where both the columnName and propertyName are null.

  1. … 1 more file in changeset.
MODE-1095 Fix support for ORDER BY using a column that isn't in the SELECT

The query framework was changed to ensure all columns used in the ORDER BY clauses

are automatically included in the results. Because the query processing engine

requires the columns to be in the (intermediate/internal) results, including the

columns in the user's result set does not make the query system less efficient.

(In fact, changing the result set to contain/expose only those columns included

in the SELECT clause would actually require additional resources and could be

potentially less efficient.)

This change implements the functionality by adding a new optimizer rule that

rewrites part of the query plan. In particular, the new rule looks for SORT query

plan nodes, processes the Ordering instances to extract the property references,

and adds corresponding columns to all the appropriate PROJECT nodes that are below

the SORT node.

This change altered the query plans for queries with orderings, so the expected

results needed to be changed in several test cases.

  1. … 10 more files in changeset.
Fixed javadoc errors that occurred when moving from Eclipse Helios to Eclipse Indigo. Also fixed a pom error that occurred when upgrading Eclipse.

  1. … 20 more files in changeset.
MODE-1496 JCR-3313 Added fixed JCR TCK test and corrected result set column behavior

Corrected the behavior of query result column names when the query contains a wildcard in the SELECT statement.

  1. … 9 more files in changeset.
MODE-1468 Corrected JCR-JQOM functionality

Corrected a lot of incorrect JCR-JQOM functionality, especially in the QueryObjectModel

instances' string statements, which are now completely parsable as JCR-SQL2. Thus,

one can always convert QOM to JCR-SQL2 -- and since we internally parse the JCR-SQL2

as a QOM, we can actually go full circle.

That wasn't the only correction. When using the QOM, literal values can take on a different

form; the same form as when using explicit "CAST(...)" functions in JCR-SQL2. But since

CASTs are not often used, executing a typical JCR-SQL2 with string literals worked well

but executing a QOM with correctly-typed literals didn't. Now, executing a QOM with

string-form literals or properly-typed literals works the same way.

Additionally, many of the TCK QOM tests pointed out deficiencies in our QOM validation

and results. Most of these were corrected, although several outstanding problems are now

described by other issues (MODE-1485, MODE-1095, and JCR-3313).

All tests pass with these changes.

  1. … 55 more files in changeset.
MODE-1418 Corrected certain queries with full-text search criteria

Certain JCR-SQL2 full-text search criteria were not being processed correctly.

Any f.t.s. criteria that specified a single property resulted in an incorrect

query plan.

Several changes were made to correct this behavior, and new unit tests were added.

  1. … 2 more files in changeset.
MODE-1365 Added more support for queries

Lots of changes in the portions of the ModeShape code that's using Lucene, including the

general interfaces and reusable queries (in org.modeshape.jcr.query.lucene) and the basic

schema that uses a single index (in org.modeshape.jcr.query.lucene.basic).

At this point, all query functionality appears to work except for full-text search.

All current tests pass with these changes, though more testing is required.

  1. … 95 more files 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.

  1. … 3647 more files in changeset.