Currently we're doing something manually, which, since Qt6 is a
dedicated feature. Use that instead for less error-prone disconnections
for our single-shot signals.
Lets not re-invent the wheel for something that has been (potentially
faster rather then slower) invented for this exact usecase.
We will promote the usage of Qt::SingleShotConnection, so as good
teachers we should be using it as well.
Pick-to: 6.8
Change-Id: I3b2b9f176f06d91b4d0946a38c53a4c2614c8a01
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This was forgotten when we switched to unique_ptr's.
Pick-to: 6.8.0 6.8
Change-Id: I684639bbafc65ea5eea34074a77367b82c9d9054
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
We obviously store the lambda and its context forever. Add the explicit
disconnect to cleanup the memory on failure.
Pick-to: 6.8
Change-Id: I1afda515f8c8dc96fec9edb847ee26efd8802c6b
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
The use of shared pointers has potential risk of storing the
QGrpcOperation children forever and leaking in user code. The problem
is clearly in the lambda connections that we encourage to use in the
docs and examples:
auto stream = testStream(...);
QObject::connect(stream.get(), &QGrpcOperation::finished,
ctx, [ctx, stream]{...});
The above code will hold the 'stream' forever, unless user will make
the explicit disconnect in the lambda.
By using std::unique_ptr we partially solve this, or at least convince
user to solve this. When user creates lambda he knows the 'stream'
lifetime and most probably should consider that after the move, lambda
is owning the QGrpcOperation, so the need of disconnect is more clear
in this case:
auto stream = testStream(...);
auto *streamPtr = stream.get();
QObject::connect(streamPtr, &QGrpcOperation::finished,
ctx, [ctx, stream = std::move(stream)]{...});
The code becomes a bit more complicated, but it points explicitly to
the potential risk. Also it disallows to make this trick to multiple
lambdas at the same time.
Of course using the lambda context to control the QGrpcOperation
lifetime in this case is not necessary. But even if users will decide
to manage the QGrpcOperation lifetime differently, the use of
std::unique_ptr will clearly point to the ownership.
[ChangeLog][Grpc] All generated RPC methods now return std::unique_ptr
instead of std::shared_ptr. This change explicitly defines that caller
takes the ownership of the returned pointers.
Pick-to: 6.8
Change-Id: I271b91454f0c1b12b77127a7e025fa493367e279
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
The header includes were not up-to-date.
Task-number: QTBUG-123625
Pick-to: 6.8
Change-Id: Id2a3d21925a0bf2ec6c8dfcb44617db3a8d5059c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
There is likely already an instantiation available for it. Prefer the
usage of QHash to stay within the (Qt) lib boundary.
Remove qgrpcdefs.h as it's now obsolete. Update all occurrences of
QGrpcMetadata.
Task-number: QTBUG-123625
Pick-to: 6.8
Change-Id: Ida7bcd851c2d4b247c1b7a8dccddc3d518e0b5ae
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This will make it easier to re-use it. This enum has a high chance of
being reused in the future.
Task-number: QTBUG-123625
Pick-to: 6.8
Change-Id: I587a2ae41e85b03539bc6213f53851ac37a415df
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The signal is the redundant attempt to make Qt-style primitives. It
increases the usage complexity without any visible advantages. The
finished signal should instead accept the QGrpcStatus code and allow
users to make the descisions about the success of the operation in a
single call stack.
[ChangeLog][GRPC] The QGrpcOperation::errorOccurred and
QGrpcChannelOperation::errorOccurred signals are removed.
[ChangeLog][GRPC] The QGrpcOperation::finished and
QGrpcChannelOperation::finished signals now have QGrpcStatus argument
that indicates the status received from the server-side for the
operation.
Task-number: QTBUG-123625
Change-Id: I87669e0921c41cef0ff9d408bed1b057ba5198f2
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The host URI is not an optional property of the QGrpcHttp2Channel and
has not relations to QGrpcChannelOptions. We should move it to the
QGrpcHttp2Channel and use it there directly instead of making the
assumption that any channel should be created using the host URI. This
also removes the requirement of having the options as mandatory
argument to construct the gRPC channels.
Task-number: QTBUG-123625
Change-Id: I6cd64bad6c379f8875dcd6794a95bf68b46da605
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It was concluded that we will use the 'set~()' syntax in our options but
still return a reference to allow chaining.
Task-number: QTBUG-123625
Change-Id: I00838465b485d096b4b7bd3d691d24385543d662
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
There are no particular reasons for these prefixes. Remove them.
[ChangeLog][GRPC] The 'stream' prefix is removed for all generated
streaming methods.
Task-number: QTBUG-123625
Change-Id: Ie1e63a6c559e259956aa3b4b72aa3ef380df4f44
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Originally motivated by Axivion(SV3), which nagged about the const
errorOccurred signal; this patch removes signal emission for failed
deserialization in the read() functions. Immediately handling this can
lead to better user code as an fallback mechanism can avoid further
execution of unneeded logic.
This patch makes the errorOcurred signal non-const and changes the
signature of the read methods to either return an optional or bool to
signal failure immediately.
Users can then retrieve the error through 'deserializationError()' or
'deserializationErrorString()'. This can be seen in the generated QML
integration code, which uses those to still emit the 'errorOcurred'
signal on deserialization failure.
Change-Id: Ie6761753145536a42d5dd5bf1eac18afa555581a
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
According to QUIP-18 [1], all example files should be
LicenseRef-Qt-Commercial OR BSD-3-Clause
[1]: https://contribute.qt-project.org/quips/18
Pick-to: 6.7
Task-number: QTBUG-121787
Change-Id: If6b8c8eb88c8880e6e277f472dfdd5b380a5c83d
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Move functionality related to the registration of the protobuf messages
to a separate header/source files.
Task-number: QTBUG-120931
Change-Id: I6076b41139d43982148e46f5f315808509c4db65
Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
Make the error from the gRPC channel visible to user.
Pick-to: 6.6
Change-Id: I0c41228612beb5c1c665f79f60d14c607f5739f8
Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
Rename QGrpcStream and all related functionality to QGrpcServerStream
and corresponding names. The stream only implements server-side
streaming, and should be named accordingly.
Task-number: QTBUG-105494
Change-Id: I6b94452a447609186b1aa68ff8795293eef9dc28
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
Protobuf allows the following construction:
message A {
enum AEnum {
AVal0 = 0;
}
B.BEnum val = 1;
}
message B {
enum BEnum {
BVal0 = 0;
}
A.AEnum val = 1;
}
This requires forward declaration of nested enums, that is not possible
in C++. To solve this problem we may do the same trick that we do
for nested messages already.
This patch moves the nested enum type out of class to the
_QtProtobufNested namespace. The solution require the enum name
specification when using enums from this moment, since the owning
messages only contain type aliases now. So from example above to access
the AVal0 you need to use the full qualifier:
A::AEnum::AVal0
The new generated code structure registrates Qml types using the built-in
macros, that unlocks direct linking of backing library without the need
of Qml plugin usage.
[ChangeLog][Protobuf] Nested enums moved out of message classes to the
nested namespace, same as the nested messages.
[ChangeLog][Protobuf][Qml] The geneated protobuf Qml modules do not
require the use of Qml plugins.
Fixes: QTBUG-115800
Change-Id: Ia67fcbecf492c3fd41350eada4d62fc9e5ea4dab
Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Use QGrpcChannelOptions and QGrpcMetadata to set up user-password
authentication for SimpleChatEngine.
Task-number: QTBUG-111037
Change-Id: I2e7dea87d542b4f7585b0724a45c1398fa2047b5
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Introduce alias to std::multimap names QGrpcMetadata, to represent
additional HTTP headers, that can be added to channel and call options.
Then channel implementations can use QGrpcMetadata and append all
metadata do each call (TODO).
Task-number: QTBUG-111037
Change-Id: Ie16e658407a57a5f44bc1a0ff54dcb3ca8b06fe1
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Use the new classes to store call and channel options used to
create gRPC channels and perform gRPC calls.
Add QGrpcCallOptions parameter to call() and startStream() methods.
Change constructor parameter of QGrpcHttp2Channel and QGrpcChannel
to QGrpcChannelOptions that stores previous parameters used to
construct channel. Add additional deadline option to be able to
configure call timeout.
[ChangeLog] Add QGrpcCallOptions to store and process additional
call options.
[ChangeLog] Add QGrpcChannelOptions to store and process channel
options and default call options.
Task-number: QTBUG-111037
Change-Id: Icd92e95c036fb5b4c268907ab912fcf59ef9a69a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Backport the simple chat example. The application implements a simple
messenger using Qt GRPC. It shows how to utilize the server-side
streaming and use the call-based user/password credentials.
Task-number: QTBUG-109598
Pick-to: 6.5
Change-Id: I4ca3695780a9cc9991c92c4423e3af9d8e0eaf35
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Dennis Oberst
Alexey Edelev
Lucie Gérard
Tatiana Borisova
Konrad Kujawa