Open-source graph database, built for real-time streaming data, compatible with Neo4j.
cyphergraphgraph-algorithmsgraph-analysisgraph-databasekafkakafka-streamsnosqlopencypherstream-processingstreaming-data
017dec8c0e
Summary:
# Summary
## Concepts and terminology
A **namestring for <object>** is a Lisp string that names the C++ language element
`<object>` (such as a namespace, a variable, a class, etc.). Therefore we have a
"namestring for a namespace", a "namestring for a variable", etc.
A **designator for a namestring for <object>** is a Lisp object that denotes a
"namestring for <object>". These are symbols and strings themselves.
A **typestring** is a Lisp string that represents a C++ type, i.e. its
declaration.
A **typestring designator** is a Lisp object that denotes a typestring.
A typestring (and the corresponding C++ type) is said to be **supported** if it
can be parsed using `parse-cpp-type-declaration`. This concept is important and
should form the base of our design because we can't really hope to ever support
all of C++'s type declarations.
A typestring (and the corresponding C++ type) that is not supported is
**unsupported**.
A **processed typestring** is a typestring that is either fully qualified or
unqualified.
A C++ type is said to be **known** if LCP knows extra information about the type,
rather than just what kind of type it is, in which namespace it lives, etc. For
now, the only known types are those that are defined within LCP itself using
`define-class` & co.
A C++ type is **unknown** if it is not known.
**Typestring resolution** is the process of resolving a (processed) typestring
into an instance of `cpp-type` or `unsupported-cpp-type`.
**Resolving accessors** are accessors which perform typestring resolution.
## Changes
Explicitly introduce the concept of supported and known types. `cpp-type` models
supported types while `unsupported-cpp-type` models unsupported types.
Subclasses of `cpp-type` model known types. `general-cpp-type` is either a
`cpp-type` or an `unsupported-cpp-type`.
Add various type queries.
Fix `define-rpc`'s `:initarg` (remove it from the `cpp-member` struct).
Introduce namestrings and their designators in `names.lisp`.
Introduce typestrings and their designators.
Introduce **processed typestrings**. Our DSL's macros (`define-class` & co.)
convert all of the given typestrings into processed typestrings because we don't
attempt to support partially qualified names and relative name lookup yet. A
warning is signalled when a partially qualified name is treated as a fully
qualified name.
The slots of `cpp-type`, `cpp-class`, `cpp-member` and `cpp-capnp-opts` now
store processed typestrings which are lazily resolved into their corresponding
C++ types.
The only thing that instances of `unsupported-cpp-type` are good for is getting
the typestring that was used to construct them. Most of LCP's functions only
work with known C++ types, i.e. `cpp-type` instances. The only function so far
that works for both of them is `cpp-type-decl`.
Since "unsupportedness" is now explicitly part of LCP, client code is expected
to manually check whether a returned type is unsupported or not (or face
receiving an error otherwise), unless a function is documented to return only
`cpp-type` instances.
A similar thing goes for "knowness". Client code is expected to manually check
whether a returned type is known or not, unless a function is documented to
return only (instances of `cpp-type` subclasses) known types.
## TODO
Resolution still has to be done for the following slots of the
following structures:
- `slk-opts`
- `save-args`
- `load-args`
- `clone-opts`
- `args`
- `return-type`
Reviewers: teon.banek, mtomic
Reviewed By: teon.banek
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D1962
|
||
|---|---|---|
| cmake | ||
| config | ||
| customers | ||
| docs | ||
| environment | ||
| experimental | ||
| libs | ||
| poc | ||
| release | ||
| src | ||
| tests | ||
| tools | ||
| .arcconfig | ||
| .arclint | ||
| .clang-format | ||
| .clang-tidy | ||
| .gdbinit | ||
| .gitignore | ||
| .ycm_extra_conf.py | ||
| apollo_archives.py | ||
| apollo_archives.yaml | ||
| apollo_build.yaml | ||
| CHANGELOG.md | ||
| CMakeLists.txt | ||
| Doxyfile | ||
| Doxylogo.png | ||
| init | ||
| README.md | ||
memgraph
Memgraph is an ACID compliant high performance transactional distributed in-memory graph database featuring runtime native query compiling, lock free data structures, multi-version concurrency control and asynchronous IO.
dependencies
Memgraph can be compiled using any modern c++ compiler. It mostly relies on the standard template library, however, some things do require external libraries.
Some code contains linux-specific libraries and the build is only supported on a 64 bit linux kernel.
- linux
- clang 3.8 (good c++11 support, especially lock free atomics)
- antlr (compiler frontend)
- cppitertools
- fmt format
- google benchmark
- google test
- glog
- gflags