-
Notifications
You must be signed in to change notification settings - Fork 35
3.9.0 Deprecations and breaking changes
Given the new Promise
/ Future
APIs the start(Future<Void>)
and stop(Future<Void>)
methods have been deprecated and will be removed in Vert.x 4.
Please migrate to the start(Promise<Void>)
and stop(Promise<Void>)
variants.
https://github.com/eclipse-vertx/vert.x/issues/3337
EDNS is an extension mechanism for DNS (https://fr.wikipedia.org/wiki/EDNS) that should be disabled by default. It might cause unwanted issue and should be disabled by default.
https://github.com/eclipse-vertx/vert.x/issues/3328
Vert.x supports multiple handler per future since the 3.8.4 release. The setHandler
method does convey the meaning that a single handler per future can be set and unset and the onComplete
, onSuccess
, onFailure
methods shall be used instead.
The setHandler
method usage should be replaced by the onComplete
method, e.g
// Before
Future<String> fut = getSomeFuture();
fut.setHandler(ar -> ...);
// After
Future<String> fut = getSomeFuture();
fut.onComplete(ar -> ...);
The setHandler
will be removed in Vert.x 4.
The documentation is removed, however the feature remains
The query API becomes fluent with the addition of a Query
API for creation and configuration of queries before their execution.
The current PreparedQuery
API is changed such as it extends Query
and becomes used outside of a connection context. A new PreparedStatement
API is therefore introduced that allows for prepared statement management and execution of prepared statements spanning several interactions such as a cursor or a stream.
Query collectors now becomes part of the Query
interface.
This is a breaking API change done under the tech preview status given that SQL client is a Vert.x 4 feature back-ported to Vert.x 3.
// Before
client.query(sql, ar -> ...);
// After
Query<RowSet<Row>> query = client.query(sql);
query.execute(ar -> ...);
// Or fluently
client.query(sql).execute(ar -> ...);
// Before
client.preparedQuery(sql, tuple, ar -> ...);
client.preparedQuery(sql, tuple, collector, ar -> ...);
// After
PreparedQuery<RowSet<Row>> query = client.preparedQuery(sql);
query.execute(tuple, ar -> ...);
// Or fluently
client.preparedQuery(sql).execute(tuple, ar -> ...);
client.preparedQuery(sql).collecting(collector).execute(tuple, ar -> ...);
// Before
client.preparedQuery(sql, tuple, collector, ar -> ...);
// After
PreparedQuery<RowSet<Row>> query = client.preparedQuery(sql);
PreparedQuery<SqlResult<List<Row>> collectedQuery = query.collecting(Collectors.toList());
collectedQuery.execute(tuple, ar -> ...);
// Or fluently
client.preparedQuery(sql).collecting(Collectors.toList()).execute(tuple, ar -> ...);
// Before
client.preparedBatch(sql, listOfTuples, ar -> ...);
// After
client.preparedQuery(sql).executeBatch(listOfTuples, ar -> ...);
// Before
connection.prepare(sql, ar1 -> {
if (ar1.succeded()) {
PreparedStatement ps = ar1.result();
ps.execute(tuple, ar2 -> ...);
}
});
// After
connection.prepare(sql, ar1 -> {
if (ar1.succeded()) {
PreparedStatement ps = ar1.result();
PreparedQuery<RowSet<Row>> pq = ps.query();
pq.execute(tuple, ar2 -> ...);
// Or fluently
ps.query().execute(tuple, ar2 -> ...);
}
});
https://github.com/vert-x3/vertx-kafka-client/commit/47fcc755f4b85bc1f3f2cef17a14ec72c8baf449
The AdminUtils
class, for doing administrative operations on a Kafka cluster, was removed. The new KafkaAdminClient
class should be used for that.