Aliases

It is expected that Aliases are used for most processing rather than the direct index name.

That is, there will be an alias say "customer" and that will initially map to the "customer_v1" index and over time there might be a change in mapping, re-indexing etc and the "customer" alias points to "customer_v2", "customer_v3" etc.

Ebean generates "versioned" (*_v1) index mapping files and when using dropCreate=true it will create indexes with the version suffix (_v1) and also create an alias to those indexes.

Just as with large OLTP databases re-indexing can be relatively expensive and take significant time and there are devops component/effort around maintaining indexes and aliases. Ebean provides some features to help in this area.

Indexing by partition

It would be useful in some cases to be able to index by a partition like day, week, month etc. This is currently not supported.

Create index

Creates an index with the option of also creating an alias to map to the index.

This will load an associated mapping file as a resource from the class path. 

// create a new index without an alias
// ... the mapping is loaded from classpath as a resource
documentStore.createIndex("product_copy", null);

Drop index

Drop a index. 

documentStore.dropIndex("product_copy");

Copy index

This does not hit the database but instead uses an ElasticSearch scroll query to go through the ElasticSearch index and use the index source to send to the destination index.

This could be used as part of a devops index migration task.

Example: Copy index - All

// scroll the product index sending the source documents to "product_copy"
long docCount = documentStore.copyIndex(Product.class, "product_copy");

Example: Copy index - Query

You can specify a query filter such that only part of the index is copied. This could be used to update an index with recent changes or to partition a single index copy task into multiple tasks that could be executed in parallel. 

Query<Product> query = server.find(Product.class)
  .where()
  .ge("whenModified", new Timestamp(since))
  .istartsWith("sku", "c")
  .query();

int bulkBatchSize = 1000;
long docCount = documentStore.copyIndex(query, "product_copy", bulkBatchSize);

Index all

This uses the database as the "source" and will execute a findEach query to iterate all the rows (ORM graphs actually) and index them.

This is expected to be more useful for testing and during development. 

// query all countries and index them
documentStore.indexAll(Country.class);

Index by query

This is similar to indexAll by using the database as the "source" and will execute a findEach query to iterate all the rows (ORM graphs) and index them. 

Query<Product> query = server.find(Product.class)
  .where()
  .ge("whenModified", new Timestamp(since))
  .startsWith("sku", "C")
  .query();

  server.docStore().indexByQuery(query, 1000);