Replace boost with capnp in RPC
Summary:
Converts the RPC stack to use Cap'n Proto for serialization instead of
boost. There are still some traces of boost in other places in the code,
but most of it is removed. A future diff should cleanup boost for good.
The RPC API is now changed to be more flexible with regards to how
serialize data. This makes the simplest cases a bit more verbose, but
allows complex serialization code to be correctly written instead of
relying on hacks. (For reference, look for the old serialization of
`PullRpc` which had a nasty pointer hacks to inject accessors in
`TypedValue`.)
Since RPC messages were uselessly modeled via inheritance of Message
base class, that class is now removed. Furthermore, that approach
doesn't really work with Cap'n Proto. Instead, each message type is
required to have some type information. This can be automated, so
`define-rpc` has been added to LCP, which hopefully simplifies defining
new RPC request and response messages.
Specify Cap'n Proto schema ID in cmake
This preserves Cap'n Proto generated typeIds across multiple generations
of capnp schemas through LCP. It is imperative that typeId stays the
same to ensure that different compilations of Memgraph may communicate
via RPC in a distributed cluster.
Use CLOS for meta information on C++ types in LCP
Since some structure slots and functions have started to repeat
themselves, it makes sense to model C++ meta information via Common Lisp
Object System.
Depends on D1391
Reviewers: buda, dgleich, mferencevic, mtomic, mculinovic, msantl
Reviewed By: msantl
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1407
2018-06-04 15:48:48 +08:00
|
|
|
#>cpp
|
|
|
|
#pragma once
|
|
|
|
|
|
|
|
#include <tuple>
|
|
|
|
|
|
|
|
#include "communication/rpc/messages.hpp"
|
|
|
|
#include "distributed/bfs_rpc_messages.capnp.h"
|
|
|
|
#include "distributed/bfs_subcursor.hpp"
|
2018-09-28 22:29:27 +08:00
|
|
|
#include "query/frontend/semantic/symbol_table.hpp"
|
|
|
|
#include "query/plan/distributed_ops.hpp"
|
|
|
|
#include "query/serialization.hpp"
|
2018-11-07 01:15:55 +08:00
|
|
|
#include "storage/distributed/rpc/serialization.hpp"
|
Replace boost with capnp in RPC
Summary:
Converts the RPC stack to use Cap'n Proto for serialization instead of
boost. There are still some traces of boost in other places in the code,
but most of it is removed. A future diff should cleanup boost for good.
The RPC API is now changed to be more flexible with regards to how
serialize data. This makes the simplest cases a bit more verbose, but
allows complex serialization code to be correctly written instead of
relying on hacks. (For reference, look for the old serialization of
`PullRpc` which had a nasty pointer hacks to inject accessors in
`TypedValue`.)
Since RPC messages were uselessly modeled via inheritance of Message
base class, that class is now removed. Furthermore, that approach
doesn't really work with Cap'n Proto. Instead, each message type is
required to have some type information. This can be automated, so
`define-rpc` has been added to LCP, which hopefully simplifies defining
new RPC request and response messages.
Specify Cap'n Proto schema ID in cmake
This preserves Cap'n Proto generated typeIds across multiple generations
of capnp schemas through LCP. It is imperative that typeId stays the
same to ensure that different compilations of Memgraph may communicate
via RPC in a distributed cluster.
Use CLOS for meta information on C++ types in LCP
Since some structure slots and functions have started to repeat
themselves, it makes sense to model C++ meta information via Common Lisp
Object System.
Depends on D1391
Reviewers: buda, dgleich, mferencevic, mtomic, mculinovic, msantl
Reviewed By: msantl
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1407
2018-06-04 15:48:48 +08:00
|
|
|
#include "transactions/type.hpp"
|
2019-02-12 19:59:37 +08:00
|
|
|
#include "rpc/serialization.hpp"
|
Replace boost with capnp in RPC
Summary:
Converts the RPC stack to use Cap'n Proto for serialization instead of
boost. There are still some traces of boost in other places in the code,
but most of it is removed. A future diff should cleanup boost for good.
The RPC API is now changed to be more flexible with regards to how
serialize data. This makes the simplest cases a bit more verbose, but
allows complex serialization code to be correctly written instead of
relying on hacks. (For reference, look for the old serialization of
`PullRpc` which had a nasty pointer hacks to inject accessors in
`TypedValue`.)
Since RPC messages were uselessly modeled via inheritance of Message
base class, that class is now removed. Furthermore, that approach
doesn't really work with Cap'n Proto. Instead, each message type is
required to have some type information. This can be automated, so
`define-rpc` has been added to LCP, which hopefully simplifies defining
new RPC request and response messages.
Specify Cap'n Proto schema ID in cmake
This preserves Cap'n Proto generated typeIds across multiple generations
of capnp schemas through LCP. It is imperative that typeId stays the
same to ensure that different compilations of Memgraph may communicate
via RPC in a distributed cluster.
Use CLOS for meta information on C++ types in LCP
Since some structure slots and functions have started to repeat
themselves, it makes sense to model C++ meta information via Common Lisp
Object System.
Depends on D1391
Reviewers: buda, dgleich, mferencevic, mtomic, mculinovic, msantl
Reviewed By: msantl
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1407
2018-06-04 15:48:48 +08:00
|
|
|
cpp<#
|
|
|
|
|
|
|
|
(lcp:namespace distributed)
|
|
|
|
|
|
|
|
(lcp:capnp-namespace "distributed")
|
|
|
|
|
2018-10-04 19:01:23 +08:00
|
|
|
(lcp:capnp-import 'ast "/query/frontend/ast/ast_serialization.capnp")
|
2018-09-28 22:29:27 +08:00
|
|
|
(lcp:capnp-import 'dist-ops "/query/plan/distributed_ops.capnp")
|
|
|
|
(lcp:capnp-import 'query "/query/serialization.capnp")
|
2018-11-07 01:15:55 +08:00
|
|
|
(lcp:capnp-import 'storage "/storage/distributed/rpc/serialization.capnp")
|
2019-02-12 19:59:37 +08:00
|
|
|
(lcp:capnp-import 'utils "/rpc/serialization.capnp")
|
Replace boost with capnp in RPC
Summary:
Converts the RPC stack to use Cap'n Proto for serialization instead of
boost. There are still some traces of boost in other places in the code,
but most of it is removed. A future diff should cleanup boost for good.
The RPC API is now changed to be more flexible with regards to how
serialize data. This makes the simplest cases a bit more verbose, but
allows complex serialization code to be correctly written instead of
relying on hacks. (For reference, look for the old serialization of
`PullRpc` which had a nasty pointer hacks to inject accessors in
`TypedValue`.)
Since RPC messages were uselessly modeled via inheritance of Message
base class, that class is now removed. Furthermore, that approach
doesn't really work with Cap'n Proto. Instead, each message type is
required to have some type information. This can be automated, so
`define-rpc` has been added to LCP, which hopefully simplifies defining
new RPC request and response messages.
Specify Cap'n Proto schema ID in cmake
This preserves Cap'n Proto generated typeIds across multiple generations
of capnp schemas through LCP. It is imperative that typeId stays the
same to ensure that different compilations of Memgraph may communicate
via RPC in a distributed cluster.
Use CLOS for meta information on C++ types in LCP
Since some structure slots and functions have started to repeat
themselves, it makes sense to model C++ meta information via Common Lisp
Object System.
Depends on D1391
Reviewers: buda, dgleich, mferencevic, mtomic, mculinovic, msantl
Reviewed By: msantl
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1407
2018-06-04 15:48:48 +08:00
|
|
|
|
|
|
|
(lcp:capnp-type-conversion "storage::EdgeAddress" "Storage.Address")
|
|
|
|
(lcp:capnp-type-conversion "storage::VertexAddress" "Storage.Address")
|
2018-12-05 19:45:16 +08:00
|
|
|
(lcp:capnp-type-conversion "storage::EdgeType" "Storage.EdgeType")
|
Replace boost with capnp in RPC
Summary:
Converts the RPC stack to use Cap'n Proto for serialization instead of
boost. There are still some traces of boost in other places in the code,
but most of it is removed. A future diff should cleanup boost for good.
The RPC API is now changed to be more flexible with regards to how
serialize data. This makes the simplest cases a bit more verbose, but
allows complex serialization code to be correctly written instead of
relying on hacks. (For reference, look for the old serialization of
`PullRpc` which had a nasty pointer hacks to inject accessors in
`TypedValue`.)
Since RPC messages were uselessly modeled via inheritance of Message
base class, that class is now removed. Furthermore, that approach
doesn't really work with Cap'n Proto. Instead, each message type is
required to have some type information. This can be automated, so
`define-rpc` has been added to LCP, which hopefully simplifies defining
new RPC request and response messages.
Specify Cap'n Proto schema ID in cmake
This preserves Cap'n Proto generated typeIds across multiple generations
of capnp schemas through LCP. It is imperative that typeId stays the
same to ensure that different compilations of Memgraph may communicate
via RPC in a distributed cluster.
Use CLOS for meta information on C++ types in LCP
Since some structure slots and functions have started to repeat
themselves, it makes sense to model C++ meta information via Common Lisp
Object System.
Depends on D1391
Reviewers: buda, dgleich, mferencevic, mtomic, mculinovic, msantl
Reviewed By: msantl
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1407
2018-06-04 15:48:48 +08:00
|
|
|
|
|
|
|
(lcp:define-rpc create-bfs-subcursor
|
|
|
|
(:request
|
|
|
|
((tx-id "tx::TransactionId" :capnp-type "UInt64")
|
|
|
|
(direction "query::EdgeAtom::Direction"
|
|
|
|
:capnp-type "Ast.EdgeAtom.Direction" :capnp-init nil
|
|
|
|
:capnp-save (lcp:capnp-save-enum "::query::capnp::EdgeAtom::Direction"
|
|
|
|
"query::EdgeAtom::Direction"
|
|
|
|
'(in out both))
|
|
|
|
:capnp-load (lcp:capnp-load-enum "::query::capnp::EdgeAtom::Direction"
|
|
|
|
"query::EdgeAtom::Direction"
|
|
|
|
'(in out both)))
|
|
|
|
(edge-types "std::vector<storage::EdgeType>"
|
2018-12-05 19:45:16 +08:00
|
|
|
:capnp-save (lcp:capnp-save-vector "::storage::capnp::EdgeType"
|
2018-09-28 22:29:27 +08:00
|
|
|
"storage::EdgeType")
|
2018-12-05 19:45:16 +08:00
|
|
|
:capnp-load (lcp:capnp-load-vector "::storage::capnp::EdgeType"
|
2018-09-28 22:29:27 +08:00
|
|
|
"storage::EdgeType"))
|
|
|
|
(filter-lambda "query::plan::ExpansionLambda"
|
2018-11-28 17:12:10 +08:00
|
|
|
:slk-load (lambda (member)
|
|
|
|
#>cpp
|
2019-02-05 20:16:07 +08:00
|
|
|
slk::Load(&self->${member}, reader, ast_storage);
|
2018-11-28 17:12:10 +08:00
|
|
|
cpp<#)
|
2018-09-28 22:29:27 +08:00
|
|
|
:capnp-type "DistOps.ExpansionLambda"
|
|
|
|
:capnp-load (lambda (reader member capnp-name)
|
|
|
|
#>cpp
|
2019-02-05 20:16:07 +08:00
|
|
|
Load(&${member}, ${reader}, ast_storage);
|
2018-09-28 22:29:27 +08:00
|
|
|
cpp<#))
|
2018-11-22 16:51:58 +08:00
|
|
|
(symbol-table "query::SymbolTable" :capnp-type "Query.SymbolTable")
|
Remove GraphDbAccessor and storage types from Ast
Summary:
This diff removes the need for a database when parsing a query and
creating an Ast. Instead of storing storage::{Label,Property,EdgeType}
in Ast nodes, we store the name and an index into all of the names. This
allows for easy creation of a map from {Label,Property,EdgeType} index
into the concrete storage type. Obviously, this comes with a performance
penalty during execution, but it should be minor. The upside is that the
query/frontend minimally depends on storage (PropertyValue), which makes
writing tests easier as well as running them a lot faster (there is no
database setup). This is most noticeable in the ast_serialization test
which took a long time due to start up of a distributed database.
Reviewers: mtomic, llugovic
Reviewed By: mtomic
Subscribers: mferencevic, pullbot
Differential Revision: https://phabricator.memgraph.io/D1774
2019-01-14 21:41:37 +08:00
|
|
|
(timestamp :int64_t)
|
|
|
|
(parameters "query::Parameters"
|
|
|
|
:capnp-type "Utils.Map(Utils.BoxInt64, Storage.PropertyValue)"))
|
2018-11-28 17:12:10 +08:00
|
|
|
(:serialize (:slk :load-args '((ast-storage "query::AstStorage *")))
|
|
|
|
(:capnp :load-args '((ast-storage "query::AstStorage *")))))
|
Replace boost with capnp in RPC
Summary:
Converts the RPC stack to use Cap'n Proto for serialization instead of
boost. There are still some traces of boost in other places in the code,
but most of it is removed. A future diff should cleanup boost for good.
The RPC API is now changed to be more flexible with regards to how
serialize data. This makes the simplest cases a bit more verbose, but
allows complex serialization code to be correctly written instead of
relying on hacks. (For reference, look for the old serialization of
`PullRpc` which had a nasty pointer hacks to inject accessors in
`TypedValue`.)
Since RPC messages were uselessly modeled via inheritance of Message
base class, that class is now removed. Furthermore, that approach
doesn't really work with Cap'n Proto. Instead, each message type is
required to have some type information. This can be automated, so
`define-rpc` has been added to LCP, which hopefully simplifies defining
new RPC request and response messages.
Specify Cap'n Proto schema ID in cmake
This preserves Cap'n Proto generated typeIds across multiple generations
of capnp schemas through LCP. It is imperative that typeId stays the
same to ensure that different compilations of Memgraph may communicate
via RPC in a distributed cluster.
Use CLOS for meta information on C++ types in LCP
Since some structure slots and functions have started to repeat
themselves, it makes sense to model C++ meta information via Common Lisp
Object System.
Depends on D1391
Reviewers: buda, dgleich, mferencevic, mtomic, mculinovic, msantl
Reviewed By: msantl
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1407
2018-06-04 15:48:48 +08:00
|
|
|
(:response ((member :int64_t))))
|
|
|
|
|
|
|
|
(lcp:define-rpc register-subcursors
|
|
|
|
(:request ((subcursor-ids "std::unordered_map<int16_t, int64_t>"
|
|
|
|
:capnp-type "Utils.Map(Utils.BoxInt16, Utils.BoxInt64)"
|
|
|
|
:capnp-save
|
2018-09-14 21:00:39 +08:00
|
|
|
(lambda (builder member capnp-name)
|
|
|
|
(declare (ignore capnp-name))
|
Replace boost with capnp in RPC
Summary:
Converts the RPC stack to use Cap'n Proto for serialization instead of
boost. There are still some traces of boost in other places in the code,
but most of it is removed. A future diff should cleanup boost for good.
The RPC API is now changed to be more flexible with regards to how
serialize data. This makes the simplest cases a bit more verbose, but
allows complex serialization code to be correctly written instead of
relying on hacks. (For reference, look for the old serialization of
`PullRpc` which had a nasty pointer hacks to inject accessors in
`TypedValue`.)
Since RPC messages were uselessly modeled via inheritance of Message
base class, that class is now removed. Furthermore, that approach
doesn't really work with Cap'n Proto. Instead, each message type is
required to have some type information. This can be automated, so
`define-rpc` has been added to LCP, which hopefully simplifies defining
new RPC request and response messages.
Specify Cap'n Proto schema ID in cmake
This preserves Cap'n Proto generated typeIds across multiple generations
of capnp schemas through LCP. It is imperative that typeId stays the
same to ensure that different compilations of Memgraph may communicate
via RPC in a distributed cluster.
Use CLOS for meta information on C++ types in LCP
Since some structure slots and functions have started to repeat
themselves, it makes sense to model C++ meta information via Common Lisp
Object System.
Depends on D1391
Reviewers: buda, dgleich, mferencevic, mtomic, mculinovic, msantl
Reviewed By: msantl
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1407
2018-06-04 15:48:48 +08:00
|
|
|
#>cpp
|
|
|
|
utils::SaveMap<utils::capnp::BoxInt16, utils::capnp::BoxInt64>(
|
|
|
|
${member}, &${builder},
|
|
|
|
[](auto *builder, const auto &entry) {
|
|
|
|
auto key_builder = builder->initKey();
|
|
|
|
key_builder.setValue(entry.first);
|
|
|
|
auto value_builder = builder->initValue();
|
|
|
|
value_builder.setValue(entry.second);
|
|
|
|
});
|
|
|
|
cpp<#)
|
|
|
|
:capnp-load
|
2018-09-20 16:55:49 +08:00
|
|
|
(lambda (reader member capnp-name)
|
|
|
|
(declare (ignore capnp-name))
|
Replace boost with capnp in RPC
Summary:
Converts the RPC stack to use Cap'n Proto for serialization instead of
boost. There are still some traces of boost in other places in the code,
but most of it is removed. A future diff should cleanup boost for good.
The RPC API is now changed to be more flexible with regards to how
serialize data. This makes the simplest cases a bit more verbose, but
allows complex serialization code to be correctly written instead of
relying on hacks. (For reference, look for the old serialization of
`PullRpc` which had a nasty pointer hacks to inject accessors in
`TypedValue`.)
Since RPC messages were uselessly modeled via inheritance of Message
base class, that class is now removed. Furthermore, that approach
doesn't really work with Cap'n Proto. Instead, each message type is
required to have some type information. This can be automated, so
`define-rpc` has been added to LCP, which hopefully simplifies defining
new RPC request and response messages.
Specify Cap'n Proto schema ID in cmake
This preserves Cap'n Proto generated typeIds across multiple generations
of capnp schemas through LCP. It is imperative that typeId stays the
same to ensure that different compilations of Memgraph may communicate
via RPC in a distributed cluster.
Use CLOS for meta information on C++ types in LCP
Since some structure slots and functions have started to repeat
themselves, it makes sense to model C++ meta information via Common Lisp
Object System.
Depends on D1391
Reviewers: buda, dgleich, mferencevic, mtomic, mculinovic, msantl
Reviewed By: msantl
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1407
2018-06-04 15:48:48 +08:00
|
|
|
#>cpp
|
|
|
|
utils::LoadMap<utils::capnp::BoxInt16, utils::capnp::BoxInt64>(
|
|
|
|
&${member}, ${reader},
|
|
|
|
[](const auto &reader) {
|
|
|
|
int16_t key = reader.getKey().getValue();
|
|
|
|
int64_t value = reader.getValue().getValue();
|
|
|
|
return std::make_pair(key, value);
|
|
|
|
});
|
|
|
|
cpp<#))))
|
|
|
|
(:response ()))
|
|
|
|
|
2018-07-06 21:12:45 +08:00
|
|
|
(lcp:define-rpc reset-subcursor
|
|
|
|
(:request ((subcursor-id :int64_t)))
|
|
|
|
(:response ()))
|
|
|
|
|
2018-09-28 22:29:27 +08:00
|
|
|
(lcp:define-enum expand-result
|
|
|
|
(success failure lambda-error)
|
2018-12-04 21:41:37 +08:00
|
|
|
(:serialize))
|
2018-09-28 22:29:27 +08:00
|
|
|
|
Replace boost with capnp in RPC
Summary:
Converts the RPC stack to use Cap'n Proto for serialization instead of
boost. There are still some traces of boost in other places in the code,
but most of it is removed. A future diff should cleanup boost for good.
The RPC API is now changed to be more flexible with regards to how
serialize data. This makes the simplest cases a bit more verbose, but
allows complex serialization code to be correctly written instead of
relying on hacks. (For reference, look for the old serialization of
`PullRpc` which had a nasty pointer hacks to inject accessors in
`TypedValue`.)
Since RPC messages were uselessly modeled via inheritance of Message
base class, that class is now removed. Furthermore, that approach
doesn't really work with Cap'n Proto. Instead, each message type is
required to have some type information. This can be automated, so
`define-rpc` has been added to LCP, which hopefully simplifies defining
new RPC request and response messages.
Specify Cap'n Proto schema ID in cmake
This preserves Cap'n Proto generated typeIds across multiple generations
of capnp schemas through LCP. It is imperative that typeId stays the
same to ensure that different compilations of Memgraph may communicate
via RPC in a distributed cluster.
Use CLOS for meta information on C++ types in LCP
Since some structure slots and functions have started to repeat
themselves, it makes sense to model C++ meta information via Common Lisp
Object System.
Depends on D1391
Reviewers: buda, dgleich, mferencevic, mtomic, mculinovic, msantl
Reviewed By: msantl
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1407
2018-06-04 15:48:48 +08:00
|
|
|
(lcp:define-rpc expand-level
|
|
|
|
(:request ((member :int64_t)))
|
2018-09-28 22:29:27 +08:00
|
|
|
(:response ((result "ExpandResult"))))
|
Replace boost with capnp in RPC
Summary:
Converts the RPC stack to use Cap'n Proto for serialization instead of
boost. There are still some traces of boost in other places in the code,
but most of it is removed. A future diff should cleanup boost for good.
The RPC API is now changed to be more flexible with regards to how
serialize data. This makes the simplest cases a bit more verbose, but
allows complex serialization code to be correctly written instead of
relying on hacks. (For reference, look for the old serialization of
`PullRpc` which had a nasty pointer hacks to inject accessors in
`TypedValue`.)
Since RPC messages were uselessly modeled via inheritance of Message
base class, that class is now removed. Furthermore, that approach
doesn't really work with Cap'n Proto. Instead, each message type is
required to have some type information. This can be automated, so
`define-rpc` has been added to LCP, which hopefully simplifies defining
new RPC request and response messages.
Specify Cap'n Proto schema ID in cmake
This preserves Cap'n Proto generated typeIds across multiple generations
of capnp schemas through LCP. It is imperative that typeId stays the
same to ensure that different compilations of Memgraph may communicate
via RPC in a distributed cluster.
Use CLOS for meta information on C++ types in LCP
Since some structure slots and functions have started to repeat
themselves, it makes sense to model C++ meta information via Common Lisp
Object System.
Depends on D1391
Reviewers: buda, dgleich, mferencevic, mtomic, mculinovic, msantl
Reviewed By: msantl
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1407
2018-06-04 15:48:48 +08:00
|
|
|
|
|
|
|
(lcp:define-rpc subcursor-pull
|
Clean-up TypedValue misuse
Summary:
In a bunch of places `TypedValue` was used where `PropertyValue` should be. A lot of times it was only because `TypedValue` serialization code could be reused for `PropertyValue`, only without providing callbacks for `VERTEX`, `EDGE` and `PATH`. So first I wrote separate serialization code for `PropertyValue` and put it into storage folder. Then I fixed all the places where `TypedValue` was incorrectly used instead of `PropertyValue`. I also disabled implicit `TypedValue` to `PropertyValue` conversion in hopes of preventing misuse in the future.
After that, I wrote code for `VertexAccessor` and `EdgeAccessor` serialization and put it into `storage` folder because it was almost duplicated in distributed BFS and pull produce RPC messages. On the sender side, some subset of records (old or new or both) is serialized, and on the reciever side, records are deserialized and immediately put into transaction cache.
Then I rewrote the `TypedValue` serialization functions (`SaveCapnpTypedValue` and `LoadCapnpTypedValue`) to not take callbacks for `VERTEX`, `EDGE` and `PATH`, but use accessor serialization functions instead. That means that any code that wants to use `TypedValue` serialization must hold a reference to `GraphDbAccessor` and `DataManager`, so that should make clients reconsider if they really want to use `TypedValue` instead of `PropertyValue`.
Reviewers: teon.banek, msantl
Reviewed By: teon.banek
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1598
2018-09-13 18:12:07 +08:00
|
|
|
(:request ((member :int64_t)))
|
2018-08-28 22:28:35 +08:00
|
|
|
(:response
|
Clean-up TypedValue misuse
Summary:
In a bunch of places `TypedValue` was used where `PropertyValue` should be. A lot of times it was only because `TypedValue` serialization code could be reused for `PropertyValue`, only without providing callbacks for `VERTEX`, `EDGE` and `PATH`. So first I wrote separate serialization code for `PropertyValue` and put it into storage folder. Then I fixed all the places where `TypedValue` was incorrectly used instead of `PropertyValue`. I also disabled implicit `TypedValue` to `PropertyValue` conversion in hopes of preventing misuse in the future.
After that, I wrote code for `VertexAccessor` and `EdgeAccessor` serialization and put it into `storage` folder because it was almost duplicated in distributed BFS and pull produce RPC messages. On the sender side, some subset of records (old or new or both) is serialized, and on the reciever side, records are deserialized and immediately put into transaction cache.
Then I rewrote the `TypedValue` serialization functions (`SaveCapnpTypedValue` and `LoadCapnpTypedValue`) to not take callbacks for `VERTEX`, `EDGE` and `PATH`, but use accessor serialization functions instead. That means that any code that wants to use `TypedValue` serialization must hold a reference to `GraphDbAccessor` and `DataManager`, so that should make clients reconsider if they really want to use `TypedValue` instead of `PropertyValue`.
Reviewers: teon.banek, msantl
Reviewed By: teon.banek
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1598
2018-09-13 18:12:07 +08:00
|
|
|
((vertex "std::experimental::optional<VertexAccessor>"
|
2018-11-28 17:12:10 +08:00
|
|
|
:slk-save (lambda (member)
|
|
|
|
#>cpp
|
|
|
|
slk::Save(static_cast<bool>(self.${member}), builder);
|
|
|
|
if (self.${member}) {
|
|
|
|
slk::Save(*self.${member}, builder,
|
|
|
|
storage::SendVersions::BOTH, worker_id);
|
|
|
|
}
|
|
|
|
cpp<#)
|
|
|
|
:slk-load (lambda (member)
|
|
|
|
#>cpp
|
|
|
|
bool has_value;
|
|
|
|
slk::Load(&has_value, reader);
|
|
|
|
if (has_value) {
|
|
|
|
self->${member} = slk::LoadVertexAccessor(reader, dba, data_manager);
|
|
|
|
}
|
|
|
|
cpp<#)
|
Clean-up TypedValue misuse
Summary:
In a bunch of places `TypedValue` was used where `PropertyValue` should be. A lot of times it was only because `TypedValue` serialization code could be reused for `PropertyValue`, only without providing callbacks for `VERTEX`, `EDGE` and `PATH`. So first I wrote separate serialization code for `PropertyValue` and put it into storage folder. Then I fixed all the places where `TypedValue` was incorrectly used instead of `PropertyValue`. I also disabled implicit `TypedValue` to `PropertyValue` conversion in hopes of preventing misuse in the future.
After that, I wrote code for `VertexAccessor` and `EdgeAccessor` serialization and put it into `storage` folder because it was almost duplicated in distributed BFS and pull produce RPC messages. On the sender side, some subset of records (old or new or both) is serialized, and on the reciever side, records are deserialized and immediately put into transaction cache.
Then I rewrote the `TypedValue` serialization functions (`SaveCapnpTypedValue` and `LoadCapnpTypedValue`) to not take callbacks for `VERTEX`, `EDGE` and `PATH`, but use accessor serialization functions instead. That means that any code that wants to use `TypedValue` serialization must hold a reference to `GraphDbAccessor` and `DataManager`, so that should make clients reconsider if they really want to use `TypedValue` instead of `PropertyValue`.
Reviewers: teon.banek, msantl
Reviewed By: teon.banek
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1598
2018-09-13 18:12:07 +08:00
|
|
|
:capnp-type "Utils.Optional(Storage.VertexAccessor)"
|
|
|
|
:capnp-save (lcp:capnp-save-optional
|
|
|
|
"storage::capnp::VertexAccessor"
|
|
|
|
"VertexAccessor"
|
2018-09-13 21:30:20 +08:00
|
|
|
"[worker_id](auto *builder, const auto &vertex) {
|
|
|
|
storage::SaveVertexAccessor(vertex, builder, storage::SendVersions::BOTH, worker_id);
|
Clean-up TypedValue misuse
Summary:
In a bunch of places `TypedValue` was used where `PropertyValue` should be. A lot of times it was only because `TypedValue` serialization code could be reused for `PropertyValue`, only without providing callbacks for `VERTEX`, `EDGE` and `PATH`. So first I wrote separate serialization code for `PropertyValue` and put it into storage folder. Then I fixed all the places where `TypedValue` was incorrectly used instead of `PropertyValue`. I also disabled implicit `TypedValue` to `PropertyValue` conversion in hopes of preventing misuse in the future.
After that, I wrote code for `VertexAccessor` and `EdgeAccessor` serialization and put it into `storage` folder because it was almost duplicated in distributed BFS and pull produce RPC messages. On the sender side, some subset of records (old or new or both) is serialized, and on the reciever side, records are deserialized and immediately put into transaction cache.
Then I rewrote the `TypedValue` serialization functions (`SaveCapnpTypedValue` and `LoadCapnpTypedValue`) to not take callbacks for `VERTEX`, `EDGE` and `PATH`, but use accessor serialization functions instead. That means that any code that wants to use `TypedValue` serialization must hold a reference to `GraphDbAccessor` and `DataManager`, so that should make clients reconsider if they really want to use `TypedValue` instead of `PropertyValue`.
Reviewers: teon.banek, msantl
Reviewed By: teon.banek
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1598
2018-09-13 18:12:07 +08:00
|
|
|
}")
|
|
|
|
:capnp-load (lcp:capnp-load-optional
|
|
|
|
"storage::capnp::VertexAccessor"
|
|
|
|
"VertexAccessor"
|
|
|
|
"[dba, data_manager](const auto &reader) {
|
|
|
|
return storage::LoadVertexAccessor(reader, dba, data_manager);
|
|
|
|
}")))
|
2018-11-28 17:12:10 +08:00
|
|
|
(:serialize (:slk :save-args '((worker-id :int16_t))
|
|
|
|
:load-args '((dba "database::GraphDbAccessor *")
|
|
|
|
(data-manager "distributed::DataManager *")))
|
|
|
|
(:capnp
|
|
|
|
:save-args '((worker-id :int16_t))
|
2018-12-04 21:41:37 +08:00
|
|
|
:load-args '((dba "database::GraphDbAccessor *")
|
|
|
|
(data-manager "distributed::DataManager *"))))))
|
2018-08-28 22:28:35 +08:00
|
|
|
|
Replace boost with capnp in RPC
Summary:
Converts the RPC stack to use Cap'n Proto for serialization instead of
boost. There are still some traces of boost in other places in the code,
but most of it is removed. A future diff should cleanup boost for good.
The RPC API is now changed to be more flexible with regards to how
serialize data. This makes the simplest cases a bit more verbose, but
allows complex serialization code to be correctly written instead of
relying on hacks. (For reference, look for the old serialization of
`PullRpc` which had a nasty pointer hacks to inject accessors in
`TypedValue`.)
Since RPC messages were uselessly modeled via inheritance of Message
base class, that class is now removed. Furthermore, that approach
doesn't really work with Cap'n Proto. Instead, each message type is
required to have some type information. This can be automated, so
`define-rpc` has been added to LCP, which hopefully simplifies defining
new RPC request and response messages.
Specify Cap'n Proto schema ID in cmake
This preserves Cap'n Proto generated typeIds across multiple generations
of capnp schemas through LCP. It is imperative that typeId stays the
same to ensure that different compilations of Memgraph may communicate
via RPC in a distributed cluster.
Use CLOS for meta information on C++ types in LCP
Since some structure slots and functions have started to repeat
themselves, it makes sense to model C++ meta information via Common Lisp
Object System.
Depends on D1391
Reviewers: buda, dgleich, mferencevic, mtomic, mculinovic, msantl
Reviewed By: msantl
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1407
2018-06-04 15:48:48 +08:00
|
|
|
(lcp:define-rpc set-source
|
|
|
|
(:request
|
|
|
|
((subcursor-id :int64_t)
|
|
|
|
(source "storage::VertexAddress")))
|
|
|
|
(:response ()))
|
|
|
|
|
|
|
|
(lcp:define-rpc expand-to-remote-vertex
|
|
|
|
(:request
|
|
|
|
((subcursor-id :int64_t)
|
|
|
|
(edge "storage::EdgeAddress")
|
|
|
|
(vertex "storage::VertexAddress")))
|
|
|
|
(:response ((member :bool))))
|
|
|
|
|
|
|
|
(lcp:define-rpc reconstruct-path
|
|
|
|
(:request
|
|
|
|
((subcursor-id :int64_t)
|
|
|
|
(vertex "std::experimental::optional<storage::VertexAddress>"
|
|
|
|
:capnp-save (lcp:capnp-save-optional "storage::capnp::Address" "storage::VertexAddress")
|
|
|
|
:capnp-load (lcp:capnp-load-optional "storage::capnp::Address" "storage::VertexAddress"))
|
|
|
|
(edge "std::experimental::optional<storage::EdgeAddress>"
|
|
|
|
:capnp-save (lcp:capnp-save-optional "storage::capnp::Address" "storage::EdgeAddress")
|
|
|
|
:capnp-load (lcp:capnp-load-optional "storage::capnp::Address" "storage::EdgeAddress")))
|
|
|
|
(:public
|
|
|
|
#>cpp
|
|
|
|
using Capnp = capnp::ReconstructPathReq;
|
|
|
|
|
|
|
|
ReconstructPathReq() {}
|
|
|
|
|
|
|
|
ReconstructPathReq(int64_t subcursor_id, storage::VertexAddress vertex)
|
|
|
|
: subcursor_id(subcursor_id),
|
|
|
|
vertex(vertex),
|
|
|
|
edge(std::experimental::nullopt) {}
|
|
|
|
|
|
|
|
ReconstructPathReq(int64_t subcursor_id, storage::EdgeAddress edge)
|
|
|
|
: subcursor_id(subcursor_id),
|
|
|
|
vertex(std::experimental::nullopt),
|
|
|
|
edge(edge) {}
|
|
|
|
cpp<#))
|
|
|
|
(:response
|
2018-11-28 17:12:10 +08:00
|
|
|
((edges "std::vector<EdgeAccessor>"
|
|
|
|
:slk-save (lambda (member)
|
|
|
|
#>cpp
|
|
|
|
size_t size = self.${member}.size();
|
|
|
|
slk::Save(size, builder);
|
|
|
|
for (const auto &v : self.${member}) {
|
|
|
|
slk::Save(v, builder, storage::SendVersions::BOTH, worker_id);
|
|
|
|
}
|
|
|
|
cpp<#)
|
|
|
|
:slk-load (lambda (member)
|
|
|
|
#>cpp
|
|
|
|
size_t size;
|
|
|
|
slk::Load(&size, reader);
|
|
|
|
self->${member}.reserve(size);
|
|
|
|
for (size_t i = 0; i < size; ++i) {
|
|
|
|
self->${member}.push_back(slk::LoadEdgeAccessor(reader, dba, data_manager));
|
|
|
|
}
|
|
|
|
cpp<#)
|
|
|
|
:capnp-type "List(Storage.EdgeAccessor)"
|
Clean-up TypedValue misuse
Summary:
In a bunch of places `TypedValue` was used where `PropertyValue` should be. A lot of times it was only because `TypedValue` serialization code could be reused for `PropertyValue`, only without providing callbacks for `VERTEX`, `EDGE` and `PATH`. So first I wrote separate serialization code for `PropertyValue` and put it into storage folder. Then I fixed all the places where `TypedValue` was incorrectly used instead of `PropertyValue`. I also disabled implicit `TypedValue` to `PropertyValue` conversion in hopes of preventing misuse in the future.
After that, I wrote code for `VertexAccessor` and `EdgeAccessor` serialization and put it into `storage` folder because it was almost duplicated in distributed BFS and pull produce RPC messages. On the sender side, some subset of records (old or new or both) is serialized, and on the reciever side, records are deserialized and immediately put into transaction cache.
Then I rewrote the `TypedValue` serialization functions (`SaveCapnpTypedValue` and `LoadCapnpTypedValue`) to not take callbacks for `VERTEX`, `EDGE` and `PATH`, but use accessor serialization functions instead. That means that any code that wants to use `TypedValue` serialization must hold a reference to `GraphDbAccessor` and `DataManager`, so that should make clients reconsider if they really want to use `TypedValue` instead of `PropertyValue`.
Reviewers: teon.banek, msantl
Reviewed By: teon.banek
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1598
2018-09-13 18:12:07 +08:00
|
|
|
:capnp-save (lcp:capnp-save-vector "storage::capnp::EdgeAccessor"
|
|
|
|
"EdgeAccessor"
|
2018-09-13 21:30:20 +08:00
|
|
|
"[worker_id](auto *builder, const auto &edge) {
|
|
|
|
storage::SaveEdgeAccessor(edge, builder, storage::SendVersions::BOTH, worker_id);
|
Clean-up TypedValue misuse
Summary:
In a bunch of places `TypedValue` was used where `PropertyValue` should be. A lot of times it was only because `TypedValue` serialization code could be reused for `PropertyValue`, only without providing callbacks for `VERTEX`, `EDGE` and `PATH`. So first I wrote separate serialization code for `PropertyValue` and put it into storage folder. Then I fixed all the places where `TypedValue` was incorrectly used instead of `PropertyValue`. I also disabled implicit `TypedValue` to `PropertyValue` conversion in hopes of preventing misuse in the future.
After that, I wrote code for `VertexAccessor` and `EdgeAccessor` serialization and put it into `storage` folder because it was almost duplicated in distributed BFS and pull produce RPC messages. On the sender side, some subset of records (old or new or both) is serialized, and on the reciever side, records are deserialized and immediately put into transaction cache.
Then I rewrote the `TypedValue` serialization functions (`SaveCapnpTypedValue` and `LoadCapnpTypedValue`) to not take callbacks for `VERTEX`, `EDGE` and `PATH`, but use accessor serialization functions instead. That means that any code that wants to use `TypedValue` serialization must hold a reference to `GraphDbAccessor` and `DataManager`, so that should make clients reconsider if they really want to use `TypedValue` instead of `PropertyValue`.
Reviewers: teon.banek, msantl
Reviewed By: teon.banek
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1598
2018-09-13 18:12:07 +08:00
|
|
|
}")
|
|
|
|
:capnp-load (lcp:capnp-load-vector "storage::capnp::EdgeAccessor"
|
|
|
|
"EdgeAccessor"
|
|
|
|
"[dba, data_manager](const auto &reader) {
|
|
|
|
return storage::LoadEdgeAccessor(reader, dba, data_manager);
|
|
|
|
}"))
|
Replace boost with capnp in RPC
Summary:
Converts the RPC stack to use Cap'n Proto for serialization instead of
boost. There are still some traces of boost in other places in the code,
but most of it is removed. A future diff should cleanup boost for good.
The RPC API is now changed to be more flexible with regards to how
serialize data. This makes the simplest cases a bit more verbose, but
allows complex serialization code to be correctly written instead of
relying on hacks. (For reference, look for the old serialization of
`PullRpc` which had a nasty pointer hacks to inject accessors in
`TypedValue`.)
Since RPC messages were uselessly modeled via inheritance of Message
base class, that class is now removed. Furthermore, that approach
doesn't really work with Cap'n Proto. Instead, each message type is
required to have some type information. This can be automated, so
`define-rpc` has been added to LCP, which hopefully simplifies defining
new RPC request and response messages.
Specify Cap'n Proto schema ID in cmake
This preserves Cap'n Proto generated typeIds across multiple generations
of capnp schemas through LCP. It is imperative that typeId stays the
same to ensure that different compilations of Memgraph may communicate
via RPC in a distributed cluster.
Use CLOS for meta information on C++ types in LCP
Since some structure slots and functions have started to repeat
themselves, it makes sense to model C++ meta information via Common Lisp
Object System.
Depends on D1391
Reviewers: buda, dgleich, mferencevic, mtomic, mculinovic, msantl
Reviewed By: msantl
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1407
2018-06-04 15:48:48 +08:00
|
|
|
(next-vertex "std::experimental::optional<storage::VertexAddress>"
|
|
|
|
:capnp-save (lcp:capnp-save-optional "storage::capnp::Address" "storage::VertexAddress")
|
|
|
|
:capnp-load (lcp:capnp-load-optional "storage::capnp::Address" "storage::VertexAddress"))
|
|
|
|
(next-edge "std::experimental::optional<storage::EdgeAddress>"
|
|
|
|
:capnp-save (lcp:capnp-save-optional "storage::capnp::Address" "storage::EdgeAddress")
|
|
|
|
:capnp-load (lcp:capnp-load-optional "storage::capnp::Address" "storage::EdgeAddress")))
|
2018-11-28 17:12:10 +08:00
|
|
|
(:serialize (:slk :save-args '((worker-id :int16_t))
|
|
|
|
:load-args '((dba "database::GraphDbAccessor *")
|
|
|
|
(data-manager "distributed::DataManager *")))
|
|
|
|
(:capnp
|
|
|
|
:save-args '((worker-id :int16_t))
|
2018-12-04 21:41:37 +08:00
|
|
|
:load-args '((dba "database::GraphDbAccessor *")
|
|
|
|
(data-manager "distributed::DataManager *"))))
|
Replace boost with capnp in RPC
Summary:
Converts the RPC stack to use Cap'n Proto for serialization instead of
boost. There are still some traces of boost in other places in the code,
but most of it is removed. A future diff should cleanup boost for good.
The RPC API is now changed to be more flexible with regards to how
serialize data. This makes the simplest cases a bit more verbose, but
allows complex serialization code to be correctly written instead of
relying on hacks. (For reference, look for the old serialization of
`PullRpc` which had a nasty pointer hacks to inject accessors in
`TypedValue`.)
Since RPC messages were uselessly modeled via inheritance of Message
base class, that class is now removed. Furthermore, that approach
doesn't really work with Cap'n Proto. Instead, each message type is
required to have some type information. This can be automated, so
`define-rpc` has been added to LCP, which hopefully simplifies defining
new RPC request and response messages.
Specify Cap'n Proto schema ID in cmake
This preserves Cap'n Proto generated typeIds across multiple generations
of capnp schemas through LCP. It is imperative that typeId stays the
same to ensure that different compilations of Memgraph may communicate
via RPC in a distributed cluster.
Use CLOS for meta information on C++ types in LCP
Since some structure slots and functions have started to repeat
themselves, it makes sense to model C++ meta information via Common Lisp
Object System.
Depends on D1391
Reviewers: buda, dgleich, mferencevic, mtomic, mculinovic, msantl
Reviewed By: msantl
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1407
2018-06-04 15:48:48 +08:00
|
|
|
(:public
|
|
|
|
#>cpp
|
|
|
|
using Capnp = capnp::ReconstructPathRes;
|
|
|
|
|
|
|
|
ReconstructPathRes() {}
|
|
|
|
|
|
|
|
ReconstructPathRes(
|
Clean-up TypedValue misuse
Summary:
In a bunch of places `TypedValue` was used where `PropertyValue` should be. A lot of times it was only because `TypedValue` serialization code could be reused for `PropertyValue`, only without providing callbacks for `VERTEX`, `EDGE` and `PATH`. So first I wrote separate serialization code for `PropertyValue` and put it into storage folder. Then I fixed all the places where `TypedValue` was incorrectly used instead of `PropertyValue`. I also disabled implicit `TypedValue` to `PropertyValue` conversion in hopes of preventing misuse in the future.
After that, I wrote code for `VertexAccessor` and `EdgeAccessor` serialization and put it into `storage` folder because it was almost duplicated in distributed BFS and pull produce RPC messages. On the sender side, some subset of records (old or new or both) is serialized, and on the reciever side, records are deserialized and immediately put into transaction cache.
Then I rewrote the `TypedValue` serialization functions (`SaveCapnpTypedValue` and `LoadCapnpTypedValue`) to not take callbacks for `VERTEX`, `EDGE` and `PATH`, but use accessor serialization functions instead. That means that any code that wants to use `TypedValue` serialization must hold a reference to `GraphDbAccessor` and `DataManager`, so that should make clients reconsider if they really want to use `TypedValue` instead of `PropertyValue`.
Reviewers: teon.banek, msantl
Reviewed By: teon.banek
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1598
2018-09-13 18:12:07 +08:00
|
|
|
const std::vector<EdgeAccessor> &edges,
|
Replace boost with capnp in RPC
Summary:
Converts the RPC stack to use Cap'n Proto for serialization instead of
boost. There are still some traces of boost in other places in the code,
but most of it is removed. A future diff should cleanup boost for good.
The RPC API is now changed to be more flexible with regards to how
serialize data. This makes the simplest cases a bit more verbose, but
allows complex serialization code to be correctly written instead of
relying on hacks. (For reference, look for the old serialization of
`PullRpc` which had a nasty pointer hacks to inject accessors in
`TypedValue`.)
Since RPC messages were uselessly modeled via inheritance of Message
base class, that class is now removed. Furthermore, that approach
doesn't really work with Cap'n Proto. Instead, each message type is
required to have some type information. This can be automated, so
`define-rpc` has been added to LCP, which hopefully simplifies defining
new RPC request and response messages.
Specify Cap'n Proto schema ID in cmake
This preserves Cap'n Proto generated typeIds across multiple generations
of capnp schemas through LCP. It is imperative that typeId stays the
same to ensure that different compilations of Memgraph may communicate
via RPC in a distributed cluster.
Use CLOS for meta information on C++ types in LCP
Since some structure slots and functions have started to repeat
themselves, it makes sense to model C++ meta information via Common Lisp
Object System.
Depends on D1391
Reviewers: buda, dgleich, mferencevic, mtomic, mculinovic, msantl
Reviewed By: msantl
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1407
2018-06-04 15:48:48 +08:00
|
|
|
std::experimental::optional<storage::VertexAddress> next_vertex,
|
Clean-up TypedValue misuse
Summary:
In a bunch of places `TypedValue` was used where `PropertyValue` should be. A lot of times it was only because `TypedValue` serialization code could be reused for `PropertyValue`, only without providing callbacks for `VERTEX`, `EDGE` and `PATH`. So first I wrote separate serialization code for `PropertyValue` and put it into storage folder. Then I fixed all the places where `TypedValue` was incorrectly used instead of `PropertyValue`. I also disabled implicit `TypedValue` to `PropertyValue` conversion in hopes of preventing misuse in the future.
After that, I wrote code for `VertexAccessor` and `EdgeAccessor` serialization and put it into `storage` folder because it was almost duplicated in distributed BFS and pull produce RPC messages. On the sender side, some subset of records (old or new or both) is serialized, and on the reciever side, records are deserialized and immediately put into transaction cache.
Then I rewrote the `TypedValue` serialization functions (`SaveCapnpTypedValue` and `LoadCapnpTypedValue`) to not take callbacks for `VERTEX`, `EDGE` and `PATH`, but use accessor serialization functions instead. That means that any code that wants to use `TypedValue` serialization must hold a reference to `GraphDbAccessor` and `DataManager`, so that should make clients reconsider if they really want to use `TypedValue` instead of `PropertyValue`.
Reviewers: teon.banek, msantl
Reviewed By: teon.banek
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1598
2018-09-13 18:12:07 +08:00
|
|
|
std::experimental::optional<storage::EdgeAddress> next_edge)
|
|
|
|
: edges(edges), next_vertex(std::move(next_vertex)), next_edge(std::move(next_edge)) {
|
Replace boost with capnp in RPC
Summary:
Converts the RPC stack to use Cap'n Proto for serialization instead of
boost. There are still some traces of boost in other places in the code,
but most of it is removed. A future diff should cleanup boost for good.
The RPC API is now changed to be more flexible with regards to how
serialize data. This makes the simplest cases a bit more verbose, but
allows complex serialization code to be correctly written instead of
relying on hacks. (For reference, look for the old serialization of
`PullRpc` which had a nasty pointer hacks to inject accessors in
`TypedValue`.)
Since RPC messages were uselessly modeled via inheritance of Message
base class, that class is now removed. Furthermore, that approach
doesn't really work with Cap'n Proto. Instead, each message type is
required to have some type information. This can be automated, so
`define-rpc` has been added to LCP, which hopefully simplifies defining
new RPC request and response messages.
Specify Cap'n Proto schema ID in cmake
This preserves Cap'n Proto generated typeIds across multiple generations
of capnp schemas through LCP. It is imperative that typeId stays the
same to ensure that different compilations of Memgraph may communicate
via RPC in a distributed cluster.
Use CLOS for meta information on C++ types in LCP
Since some structure slots and functions have started to repeat
themselves, it makes sense to model C++ meta information via Common Lisp
Object System.
Depends on D1391
Reviewers: buda, dgleich, mferencevic, mtomic, mculinovic, msantl
Reviewed By: msantl
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1407
2018-06-04 15:48:48 +08:00
|
|
|
CHECK(!static_cast<bool>(next_vertex) || !static_cast<bool>(next_edge))
|
|
|
|
<< "At most one of `next_vertex` and `next_edge` should be set";
|
|
|
|
}
|
|
|
|
cpp<#)))
|
|
|
|
|
|
|
|
(lcp:define-rpc prepare-for-expand
|
|
|
|
(:request
|
|
|
|
((subcursor-id :int64_t)
|
2018-09-28 22:29:27 +08:00
|
|
|
(clear :bool)
|
|
|
|
(frame "std::vector<query::TypedValue>"
|
2018-11-28 17:12:10 +08:00
|
|
|
:slk-save (lambda (member)
|
|
|
|
#>cpp
|
|
|
|
size_t size = self.${member}.size();
|
|
|
|
slk::Save(size, builder);
|
|
|
|
for (const auto &v : self.${member}) {
|
|
|
|
slk::Save(v, builder, storage::SendVersions::ONLY_OLD, self.worker_id);
|
|
|
|
}
|
|
|
|
cpp<#)
|
|
|
|
:slk-load (lambda (member)
|
|
|
|
#>cpp
|
|
|
|
size_t size;
|
|
|
|
slk::Load(&size, reader);
|
|
|
|
self->${member}.resize(size);
|
|
|
|
for (size_t i = 0; i < size; ++i) {
|
|
|
|
slk::Load(&self->${member}[i], reader, dba, data_manager);
|
|
|
|
}
|
|
|
|
cpp<#)
|
2018-09-28 22:29:27 +08:00
|
|
|
:capnp-type "List(Query.TypedValue)"
|
|
|
|
:capnp-save (lcp:capnp-save-vector
|
|
|
|
"query::capnp::TypedValue"
|
|
|
|
"query::TypedValue"
|
|
|
|
"[&self](auto *builder, const auto &value) {
|
|
|
|
query::SaveCapnpTypedValue(value, builder,
|
|
|
|
storage::SendVersions::ONLY_OLD, self.worker_id);
|
|
|
|
}")
|
|
|
|
:capnp-load (lcp:capnp-load-vector
|
|
|
|
"query::capnp::TypedValue"
|
|
|
|
"query::TypedValue"
|
|
|
|
"[dba, data_manager](const auto &reader) {
|
|
|
|
query::TypedValue value;
|
|
|
|
query::LoadCapnpTypedValue(reader, &value, dba, data_manager);
|
|
|
|
return value;
|
|
|
|
}"))
|
2018-11-28 17:12:10 +08:00
|
|
|
(worker-id :int16_t :dont-save t))
|
|
|
|
(:serialize (:slk :load-args '((dba "database::GraphDbAccessor *")
|
|
|
|
(data-manager "distributed::DataManager *")))
|
|
|
|
(:capnp
|
2018-12-04 21:41:37 +08:00
|
|
|
:load-args '((dba "database::GraphDbAccessor *")
|
|
|
|
(data-manager "distributed::DataManager *")))))
|
Replace boost with capnp in RPC
Summary:
Converts the RPC stack to use Cap'n Proto for serialization instead of
boost. There are still some traces of boost in other places in the code,
but most of it is removed. A future diff should cleanup boost for good.
The RPC API is now changed to be more flexible with regards to how
serialize data. This makes the simplest cases a bit more verbose, but
allows complex serialization code to be correctly written instead of
relying on hacks. (For reference, look for the old serialization of
`PullRpc` which had a nasty pointer hacks to inject accessors in
`TypedValue`.)
Since RPC messages were uselessly modeled via inheritance of Message
base class, that class is now removed. Furthermore, that approach
doesn't really work with Cap'n Proto. Instead, each message type is
required to have some type information. This can be automated, so
`define-rpc` has been added to LCP, which hopefully simplifies defining
new RPC request and response messages.
Specify Cap'n Proto schema ID in cmake
This preserves Cap'n Proto generated typeIds across multiple generations
of capnp schemas through LCP. It is imperative that typeId stays the
same to ensure that different compilations of Memgraph may communicate
via RPC in a distributed cluster.
Use CLOS for meta information on C++ types in LCP
Since some structure slots and functions have started to repeat
themselves, it makes sense to model C++ meta information via Common Lisp
Object System.
Depends on D1391
Reviewers: buda, dgleich, mferencevic, mtomic, mculinovic, msantl
Reviewed By: msantl
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1407
2018-06-04 15:48:48 +08:00
|
|
|
(:response ()))
|
|
|
|
|
|
|
|
(lcp:pop-namespace) ;; distributed
|