Статьи

Couchbase Java SDK 2.0.0 Beta 2

Январь 11, 2018

Первоначально написано Майкл Nitschinger

Вскоре после первого бета-релиза я очень рад объявить о втором бета-выпуске серии релизов Java / JVM SDK под названием Armstrong . Он содержит как основной пакет «core-io» 1.0.0-beta2, так и Java SDK 2.0.0-beta2.

Предполагается, что это будет последняя бета-версия перед финальным GA, который планируется вскоре после этого. Он содержит два основных дополнения и несколько исправлений и улучшений. Если вы новичок в 2.0 SDK в целом, пожалуйста, обратитесь к старым сообщениям в блогах ( бета-версия 1 , DP 3 , DP 2 и DP1 ), а также почему мы реагируем .

Вот как вы можете получить это:

<dependencies>
    <dependency>
        <groupId>com.couchbase.client</groupId>
        <artifactId>java-client</artifactId>
        <version>2.0.0-beta2</version>
    </dependency>
</dependencies>

<repositories>
    <repository>
        <id>couchbase</id>
        <name>couchbase repo</name>
        <url>http://files.couchbase.com/maven2</url>
        <snapshots><enabled>false</enabled></snapshots>
    </repository>
</repositories>

Вот краткое изложение новых дополнений и изменений:

Изменение имени артефакта

Мы решили переименовать артефакт couchbase-client в java-client по следующим причинам:

  • Во-первых, это позволяет нам добавлять больше языковых привязок в будущем, не нарушая схему именования (например, scala-client, jruby-client и т. Д.).
  • Во-вторых, он позволяет запускать как старый, так и новый Java SDK одновременно! Это было запрошено несколько раз пользователями, которые хотят обновляться медленно и контролируемым образом. Так как это полная перезапись по сравнению со старой, нет столкновений, которые могли бы предотвратить это.

Обязательно примите артефакт зависимости при обновлении с бета-версии 1 или более ранней.

API блокировки

Вероятно, это изменение с наибольшим влиянием, и мы решили сломать API в последний раз перед GA для большего блага. Мы получили много запросов о том, что хотя асинхронный API является очень мощным, очень часто все, что требуется, это простой API блокировки. Кроме того, привыкание к Observables и новому API — две задачи одновременно, и они могут замедлить принятие.

Поэтому мы поместили API-интерфейс синхронной оболочки вокруг асинхронного. Теперь у вас под рукой есть оба API, просто используйте тот, который соответствует вашим потребностям. Он специально разработан для одновременного использования, поэтому вы можете смешивать и сочетать в зависимости от выполняемой операции.

Все асинхронные операции теперь выполняются в интерфейсе «Асинхронный», аналогичном блокирующим. Таким образом, вы можете перейти от блокирующего API к неблокирующему, например так:

// Connect Sync
Cluster cluster = CouchbaseCluster.create();
Bucket bucket = cluster.openBucket("beer-sample");

// Load a Document sync
JsonDocument doc = bucket.get("21st_amendment_brewery_cafe");
System.out.println(doc);

// Get access to the async bucket and load the document async
AsyncBucket asyncBucket = bucket.async();
asyncBucket
    .get("21st_amendment_brewery_cafe")
    .subscribe(System.out::println);

// Disconnect sync
cluster.disconnect();

Или непосредственно создать экземпляр асинхронного клиента (это отражает предыдущее поведение):

// Connect Async
AsyncCluster cluster = CouchbaseAsyncCluster.create();
Observable<AsyncBucket> bucket = cluster.openBucket("beer-sample");

Каждый интерфейс, который обеспечивает синхронный доступ к данным, также имеет метод async (), который дает вам прямой доступ к базовой асинхронной реализации. Поэтому, если вы хотите перенести ваш код, просто используйте async (), чтобы преобразовать блокирующий экземпляр напрямую в неблокирующий.

Поскольку это изменение интерфейса, мы соответствующим образом адаптировали документацию.

Больше типов документов и транскодеров

Добавлены дополнительные типы документов (и соответствующие им транскодеры), чтобы предоставить вам более широкий диапазон сохраняемых типов по умолчанию. Этот список включает (включая уже существующий JsonDocument для объектов и LegacyDocument для взаимодействия с 1. * SDK):

  • JsonArrayDocument -> для сохранения массивов Json в качестве значения верхнего уровня
  • JsonBooleanDocument -> для сохранения Json Boolean в качестве значения
  • JsonDoubleDocument -> сохранить номер Json (double / float) в качестве значения
  • JsonLongDocument -> сохранить номер Json (long / int) в качестве значения
  • JsonStringDocument -> для сохранения Json String (в кавычках) в качестве значения
  • StringDocument -> для хранения необработанной (не JSON) строки без кавычек
  • SerializableDocument -> для хранения POJO, который реализует Serializable
  • BinaryDocument -> для хранения необработанных байтов, которые не транскодируются ни в какой форме.

Вот некоторые примеры:

bucket.upsert(JsonArrayDocument.create("array", JsonArray.from("foo", "bar")));
System.out.println(bucket.get("array", JsonArrayDocument.class));

bucket.upsert(JsonBooleanDocument.create("boolean", true));
System.out.println(bucket.get("boolean", JsonBooleanDocument.class));

bucket.upsert(JsonStringDocument.create("jstring", "Hello World"));
System.out.println(bucket.get("jstring", JsonStringDocument.class));

bucket.upsert(StringDocument.create("string", "Hello World"));
System.out.println(bucket.get("string", StringDocument.class));

Это печатает:

JsonArrayDocument{id='array', cas=9145230438450, expiry=0, content=["foo","bar"]}
JsonBooleanDocument{id='boolean', cas=9105234519913, expiry=0, content=true}
JsonStringDocument{id='jstring', cas=9105238274737, expiry=0, content=Hello World}
StringDocument{id='string', cas=9069020208964, expiry=0, content=Hello World}

Обратите внимание на разницу между JsonString, которая будет храниться в кавычках (и доступна для просмотра из пользовательского интерфейса сервера Couchbase), в то время как обычный строковый документ не будет заключаться в кавычки и храниться как «не JSON» на стороне сервера. Благодаря новой совместимости между 2.0 SDK, мета-информация, хранящаяся вместе, позволяет получать или хранить их, например, в .NET или NodeJS .

На последней миле

Мы планируем поставить 2.0.0 GA в самое ближайшее время. Мы считаем его достаточно стабильным, чтобы вы могли приступить к разработке приложений и внедрить их в производственную среду. Хотя мы прилагаем все усилия для запуска множества сценариев в средах QE, пожалуйста, наденьте шины на этот выпуск, поскольку он совершенно новый и, конечно, есть скрытые ошибки. 

Если вы найдете их, пожалуйста, немедленно поднимите их на багтрекере JCBC, чтобы мы могли их исправить до выпуска GA. Мы также планируем выпустить исправление 2.0.1 через несколько недель после GA, которое будет содержать исправления для некоторых заявленных релизов заявок.

29
Share: