Skip to main content

Migration: Server Breaking Changes

The features listed on this page were available in former RavenDB versions.
In RavenDB 6.2.x, they are either unavailable or their behavior is inconsistent with their behavior in previous versions.

MSSQL connection string requires an Encrypt property​

To establish a connection with an MSSQL server via ETL, RavenDB is required by the Microsoft.Data.SqlClient package it utilizes (which replaces the deprecated System.Data.SqlClient package we've been using in previous versions) to include in its connection string an Encrypt property that would determine whether to encrypt the connection or not.

RavenDB versions preceding 6.2 (down to 6.0.105) added this property to their connection strings without bothering their users, setting it to Encrypt=Optional and leaving the connection unencrypted unless users set it differently on their own accord.
From RavenDB 6.2 on, we no longer include this property in MSSQL connection strings and users are required to explicitly choose whether to encrypt the connection or not.

You can go on using Encrypt=Optional and leave your connection unencrypted, or include Encrypt=Mandatory or Encrypt=Strict in your connection string and provide the server you use with a valid certificate to encrypt the connection.

Provide the connection string using code (like so) or via Studio:

SQL ETL task

Corax handling of complex JSON objects in static indexes is configurable​

The behavior of RavenDB's Corax search engine while handling complex JSON objects in static indexes is now configurable using the Indexing.Corax.Static.ComplexFieldIndexingBehavior configuration option (the handling of auto indexes remains unchanged).

  • By default, ComplexFieldIndexingBehavior is set to Throw, instructing the search engine to throw a NotSupportedInCoraxException exception when it encounters a complex field in a static index.

  • If you prefer it, you can set ComplexFieldIndexingBehavior to Skip to disable the indexing of complex fields without throwing an exception or raising a notification.

  • The configuration option will apply only to new static indexes, created after the release of RavenDB 6.2. It will not affect older indexes.
  • ComplexFieldIndexingBehavior can be set for a particular index as well as for all indexes.
  • Though complex fields cannot be indexed, they can still be stored and projected.
  • To search by the contents of a static index's complex field, you can convert it to a string (using ToString on the field value in the index definition). It is recommended, though, to index individual properties of the complex field.

Customizable identifier parts separator​

Picking an identifier parts separator allows you to choose which character would be placed as a separator between ID parts when new documents are given their IDs.

This configuration is available in the database level as well as server-wide, but in versions lower than RavenDB 6.2 its server-wide level wasn't implemented even if a new separator was selected.

RavenDB 6.2 applies your identifier parts separator selection in the server-wide level as well. This means that if you selected a separator in a RavenDB version lower than 6.2 and you now migrate to 6.2, your selected separator will become active.

Please be aware of this change and check this setting before migrating.

Identity parts separator

After making this change, creating a new document with the identity prefix |, e.g. user|, will apply your new separator.

New separator

Full-text search when the analyzer splits a search term​

Starting with RavenDB 6.0.104, Corax changed how it handles a non-wildcard search term that the query-time analyzer splits into multiple tokens. For example, the default search analyzer splits sales%representative into the tokens sales and representative.

Corax behavior for versions lower than 6.0.104:​

Corax matched tokens produced from one search term as independent terms.
The search operator combined those tokens (OR by default):

  • With OR, a document matched if the searched field contained at least one of the tokens.
  • With AND, the field had to contain all the tokens.

The tokens could occur anywhere in the field and in any order.

Corax behavior for 6.0.104 and later:​

Corax matches tokens produced from one search term as a phrase. A document matches only when the tokens in the searched field are adjacent and occur in the same order as the analyzer-generated query tokens.

This aligns Corax with the existing behavior of the Lucene search engine.

After upgrading to RavenDB 6.0.104 or later, this behavior applies without a reset to Corax indexes that were created or reset in RavenDB 6.0.101 or later. Older Corax indexes retain the legacy behavior until they are reset or recreated.

See Search with analyzer-generated phrases for detailed examples.

In this article