Skip to main content

Migration: Client Breaking Changes

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

Subscription creation overload modification​

  • In RavenDB versions earlier than 7.0, the Create<T> method overload that accepted a predicate also allowed specifying a query through SubscriptionCreationOptions, which could cause errors and confusion.
  • To eliminate this ambiguity, starting from 7.0, the Create<T> overload for predicate-based subscriptions now accepts PredicateSubscriptionCreationOptions, which no longer includes a Query property.
  • Refer to the Subscription creation API overview for the complete list of available Create method overloads.
// The create overload using a predicate:
// ======================================
string Create<T>(Expression<Func<T, bool>> predicate = null,
  PredicateSubscriptionCreationOptions options = null,
  string database = null);

Task<string> CreateAsync<T>(Expression<Func<T, bool>> predicate = null,
  PredicateSubscriptionCreationOptions options = null,
  string database = null,
  CancellationToken token = default);

// The options class:
// ==================
public sealed class PredicateSubscriptionCreationOptions
{
  public string Name { get; set; }
  public string ChangeVector { get; set; }
  public string MentorNode { get; set; }
  public bool Disabled { get; set; }
  public bool PinToMentorNode { get; set; }
  public ArchivedDataProcessingBehavior? ArchivedDataProcessingBehavior { get; set; }
}

HTTP-Compression algorithm is now Zstd by default​

From RavenDB 7.0 on, the default HTTP compression algorithm is Zstd (instead of Gzip, used in earlier versions).

To switch the HTTP-compression algorithm:

Clients can switch to a different HTTP-Compression algorithm using DocumentStore's DocumentConventions.HttpCompressionAlgorithm convention.

var DocumentConventions = new DocumentConventions
{
  // Switch HTTP compression algorithm
  HttpCompressionAlgorithm = HttpCompressionAlgorithm.Gzip
};

If you migrate from an earlier RavenDB version to version 7.0 or higher,
please note the potential significance of this change.

Bulk-insert Compression is now Enabled by default​

Compression is now Enabled by default for bulk-insert operations.

CompressionLevel DefaultCompressionLevel = CompressionLevel.Fastest;

To switch the bulk-insert state:

Clients can switch to a different bulk-insert compression state using Store's BulkInsertOptions.CompressionLevel option.

using (var bulk = store.BulkInsert(new BulkInsertOptions
{
  // Disable bulk-insert compression
  CompressionLevel = CompressionLevel.NoCompression
}));

Removed irrelevant SingleNodeBatchCommand parameters​

We removed from SingleNodeBatchCommand's definition the parameters that are mainly used internally and kept only those relevant to the user.

`SingleNodeBatchCommand` signature:

public SingleNodeBatchCommand
  (DocumentConventions conventions, 
   IList<ICommandData> commands, 
   BatchOptions options = null)

Removed obsolete methods​

The following methods are no longer used and have been removed from RavenDB 7.0.

  • NextPageStart
public int NextPageStart { get; set; }
  • GenerateEntityIdOnTheClient
public GenerateEntityIdOnTheClient(DocumentConventions conventions,
                                 Func<object, string> generateId)
  • InMemoryDocumentSessionOperations.GenerateId
protected override string GenerateId(object entity)
  • InMemoryDocumentSessionOperations.GetOrGenerateDocumentIdAsync
protected async Task<string> GetOrGenerateDocumentIdAsync(object entity)

FromEtl is now internal​

The CounterBatch class FromEtl property is now internal.
FromEtl is used internally to get or set a value indicating whether a counters batch originated from an ETL process.

Deploying multiple indexes is now atomic​

This change applies to the .NET client only.

In earlier versions, IndexCreation.CreateIndexes sent all index definitions in a single request, and if that request failed it retried the deployment index-by-index. Indexes that were valid were therefore still created, and the indexes that failed were reported together in an AggregateException.

IndexCreation.CreateIndexes now delegates to DocumentStore.ExecuteIndexes, and the two methods behave identically. The batch is now atomic:

  • If any index in the batch fails to compile, the entire batch fails and none of the indexes in it are created.
  • The failure is reported as an IndexCompilationException naming the index that caused it, instead of an AggregateException.

If your deployment flow relied on the valid indexes being created despite one of them failing, deploy the indexes in separate calls, or call Execute on each index individually.

Deploying an empty list of indexes is now a no-op: no request is sent to the server and no exception is thrown.

In this article