diff --git a/.arcconfig b/.arcconfig deleted file mode 100644 index d65ecaefa..000000000 --- a/.arcconfig +++ /dev/null @@ -1,7 +0,0 @@ -{ - "project_id" : "memgraph", - "conduit_uri" : "https://phabricator.memgraph.io", - "phabricator_uri" : "https://phabricator.memgraph.io", - "git.default-relative-commit": "origin/master", - "arc.land.onto.default": "master" -} diff --git a/.arclint b/.arclint deleted file mode 100644 index e854dec99..000000000 --- a/.arclint +++ /dev/null @@ -1,16 +0,0 @@ -{ - "linters": { - "clang-tidy": { - "type": "script-and-regex", - "include": "(\\.(cpp|cc|cxx|c|h|hpp|lcp)$)", - "script-and-regex.script": "./tools/arc-clang-tidy", - "script-and-regex.regex": "/^(?P.*):(?P\\d+):(?P\\d+): (?Pwarning|error): (?P.*)$/m" - }, - "clang-format": { - "type": "script-and-regex", - "include": "(\\.(cpp|cc|cxx|c|h|hpp)$)", - "script-and-regex.script": "./tools/arc-clang-format", - "script-and-regex.regex": "/^(?Pwarning):(?P\\d+):(?P.*)$/m" - } - } -} diff --git a/.github/workflows/diff.yaml b/.github/workflows/diff.yaml index cac272151..f87ab1296 100644 --- a/.github/workflows/diff.yaml +++ b/.github/workflows/diff.yaml @@ -1,6 +1,10 @@ name: Diff -on: [push] +on: + push: + paths-ignore: + - 'docs/**' + - '*.md' jobs: community_build: diff --git a/.ycm_extra_conf.py b/.ycm_extra_conf.py deleted file mode 100644 index 0e172c1b6..000000000 --- a/.ycm_extra_conf.py +++ /dev/null @@ -1,172 +0,0 @@ -import os -import os.path -import fnmatch -import logging -import ycm_core - -BASE_FLAGS = [ - '-Wall', - '-Wextra', - '-Werror', - '-Wno-long-long', - '-Wno-variadic-macros', - '-fexceptions', - '-ferror-limit=10000', - '-std=c++1z', - '-xc++', - '-I/usr/lib/', - '-I/usr/include/', - '-I./src', - '-I./include', - '-I./libs/fmt', - '-I./libs/yaml-cpp', - '-I./libs/glog/include', - '-I./libs/googletest/googletest/include', - '-I./libs/googletest/googlemock/include', - '-I./libs/benchmark/include', - '-I./libs/cereal/include', - # We include cppitertools headers directly from libs directory. - '-I./libs', - '-I./libs/rapidcheck/include', - '-I./libs/antlr4/runtime/Cpp/runtime/src', - '-I./libs/gflags/include', - '-I./experimental/distributed/src', - '-I./libs/postgresql/include', - '-I./libs/bzip2', - '-I./libs/zlib', - '-I./libs/rocksdb/include', - '-I./libs/librdkafka/include/librdkafka', - '-I./build/include' -] - -SOURCE_EXTENSIONS = [ - '.cpp', - '.cxx', - '.cc', - '.c', - '.m', - '.mm' -] - -HEADER_EXTENSIONS = [ - '.h', - '.hxx', - '.hpp', - '.hh' -] - -# set the working directory of YCMD to be this file -os.chdir(os.path.dirname(os.path.realpath(__file__))) - -def IsHeaderFile(filename): - extension = os.path.splitext(filename)[1] - return extension in HEADER_EXTENSIONS - -def GetCompilationInfoForFile(database, filename): - if IsHeaderFile(filename): - basename = os.path.splitext(filename)[0] - for extension in SOURCE_EXTENSIONS: - replacement_file = basename + extension - if os.path.exists(replacement_file): - compilation_info = database.GetCompilationInfoForFile(replacement_file) - if compilation_info.compiler_flags_: - return compilation_info - return None - return database.GetCompilationInfoForFile(filename) - -def FindNearest(path, target): - candidate = os.path.join(path, target) - if(os.path.isfile(candidate) or os.path.isdir(candidate)): - logging.info("Found nearest " + target + " at " + candidate) - return candidate; - else: - parent = os.path.dirname(os.path.abspath(path)); - if(parent == path): - raise RuntimeError("Could not find " + target); - return FindNearest(parent, target) - -def MakeRelativePathsInFlagsAbsolute(flags, working_directory): - if not working_directory: - return list(flags) - new_flags = [] - make_next_absolute = False - path_flags = [ '-isystem', '-I', '-iquote', '--sysroot=' ] - for flag in flags: - new_flag = flag - - if make_next_absolute: - make_next_absolute = False - if not flag.startswith('/'): - new_flag = os.path.join(working_directory, flag) - - for path_flag in path_flags: - if flag == path_flag: - make_next_absolute = True - break - - if flag.startswith(path_flag): - path = flag[ len(path_flag): ] - new_flag = path_flag + os.path.join(working_directory, path) - break - - if new_flag: - new_flags.append(new_flag) - return new_flags - - -def FlagsForClangComplete(root): - try: - clang_complete_path = FindNearest(root, '.clang_complete') - clang_complete_flags = open(clang_complete_path, 'r').read().splitlines() - return clang_complete_flags - except: - return None - -def FlagsForInclude(root): - try: - include_path = FindNearest(root, 'include') - flags = [] - for dirroot, dirnames, filenames in os.walk(include_path): - for dir_path in dirnames: - real_path = os.path.join(dirroot, dir_path) - flags = flags + ["-I" + real_path] - return flags - except: - return None - -def FlagsForCompilationDatabase(root, filename): - try: - compilation_db_path = FindNearest(root, 'compile_commands.json') - compilation_db_dir = os.path.dirname(compilation_db_path) - logging.info("Set compilation database directory to " + compilation_db_dir) - compilation_db = ycm_core.CompilationDatabase(compilation_db_dir) - if not compilation_db: - logging.info("Compilation database file found but unable to load") - return None - compilation_info = GetCompilationInfoForFile(compilation_db, filename) - if not compilation_info: - logging.info("No compilation info for " + filename + " in compilation database") - return None - return MakeRelativePathsInFlagsAbsolute( - compilation_info.compiler_flags_, - compilation_info.compiler_working_dir_) - except: - return None - -def FlagsForFile(filename): - root = os.path.realpath(filename); - compilation_db_flags = FlagsForCompilationDatabase(root, filename) - if compilation_db_flags: - final_flags = compilation_db_flags - else: - final_flags = BASE_FLAGS - clang_flags = FlagsForClangComplete(root) - if clang_flags: - final_flags = final_flags + clang_flags - include_flags = FlagsForInclude(root) - if include_flags: - final_flags = final_flags + include_flags - return { - 'flags': final_flags, - 'do_cache': True - } diff --git a/CODEOWNERS b/CODEOWNERS new file mode 100644 index 000000000..f871ca5f9 --- /dev/null +++ b/CODEOWNERS @@ -0,0 +1,4 @@ +/docs/ @gitbuda +/src/communication/ @antonio2368 +/src/query/ @the-joksim +/src/storage/ @antonio2368 diff --git a/Doxyfile b/Doxyfile index 3fb0b6763..9281d1cf8 100644 --- a/Doxyfile +++ b/Doxyfile @@ -51,7 +51,7 @@ PROJECT_BRIEF = "The World's Most Powerful Graph Database" # pixels and the maximum width should not exceed 200 pixels. Doxygen will copy # the logo to the output directory. -PROJECT_LOGO = Doxylogo.png +PROJECT_LOGO = docs/doxygen/memgraph_logo.png # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path # into which the generated documentation will be written. If a relative path is diff --git a/README.md b/README.md index 6d7fe1457..a141030e3 100644 --- a/README.md +++ b/README.md @@ -1,24 +1,47 @@ -# memgraph +# 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 +## Development Documentation -Memgraph can be compiled using any modern c++ compiler. It mostly relies on -the standard template library, however, some things do require external -libraries. +* [Quick Start](docs/dev/quick-start.md) +* [Workflow](docs/dev/workflow.md) +* [Storage](docs/dev/storage/v2/contents.md) +* [Query Engine](docs/dev/query/contents.md) +* [Communication](docs/dev/communication/contents.md) +* [Lisp C++ Preprocessor (LCP)](docs/dev/lcp.md) -Some code contains linux-specific libraries and the build is only supported -on a 64 bit linux kernel. +## Feature Specifications -* linux -* clang 3.8 (good c++11 support, especially lock free atomics) -* antlr (compiler frontend) -* cppitertools -* fmt format -* google benchmark -* google test -* glog -* gflags +Each prominent Memgraph feature requires a feature specification. The purpose +of the feature specification is to have a base for discussing all aspects of +the feature. Elements of feature specifications should be: + +* High-level context. +* Interface. +* User stories. Usage from the end-user perspective. In the case of a library, + that should be cases on how to use the programming interface. In the case of +a shell script, that should be cases on how to use flags. +* Discussion about concurrency, memory management, error management. +* Any other essential functional or non-functional requirements. +* Test and benchmark strategy. +* Possible future changes/improvements/extensions. +* Security concerns. +* Additional and/or optional implementation details. + +It's crucial to keep feature spec up-to-date with the implementation. Take a +look at the list of [feature specifications](docs/feature_spec/contents.md) to +learn more about powerful Memgraph features. + +## User Documentation + +Memgraph user documentation is maintained within +[docs](https://github.com/memgraph/docs) repository. The documentation is also +available on [GitBook](https://docs.memgraph.com). + +## Licences + +* [Community](release/LICENSE_COMMUNITY.md) +* [Enterprise](release/LICENSE_ENTERPRISE.md) diff --git a/docs/dev/communication/contents.md b/docs/dev/communication/contents.md new file mode 100644 index 000000000..6b515b32a --- /dev/null +++ b/docs/dev/communication/contents.md @@ -0,0 +1,5 @@ +# Communication + +## Bolt + +Memgraph implements [Bolt communication protocol](https://7687.org/). diff --git a/docs/dev/durability/snapshots.md b/docs/dev/durability/snapshots.md deleted file mode 100644 index 32f1b3a5b..000000000 --- a/docs/dev/durability/snapshots.md +++ /dev/null @@ -1,22 +0,0 @@ -# Snapshots - -A "snapshot" is a record of the current database state stored in permanent -storage. Note that the term "snapshot" is used also in the context of -the transaction engine to denote a set of running transactions. - -A snapshot is written to the file by Memgraph periodically if so -configured. The snapshot creation process is done within a transaction created -specifically for that purpose. The transaction is needed to ensure that -the stored state is internally consistent. - -The database state can be recovered from the snapshot during startup, if -so configured. This recovery works in conjunction with write-ahead log -recovery. - -A single snapshot contains all the data needed to recover a database. In -that sense snapshots are independent of each other and old snapshots can -be deleted once the new ones are safely stored, if it is not necessary -to revert the database to some older state. - -The exact format of the snapshot file is defined inline in the snapshot -creation code. diff --git a/docs/dev/query/build-html b/docs/dev/query/build-html deleted file mode 100755 index d012f45c8..000000000 --- a/docs/dev/query/build-html +++ /dev/null @@ -1,16 +0,0 @@ -#!/bin/bash - -script_dir="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" - -mkdir -p $script_dir/html - -for markdown_file in $(find $script_dir -name '*.md'); do - name=$(basename -s .md $markdown_file) - sed -e 's/.md/.html/' $markdown_file | \ - pandoc -s -f markdown -t html -o $script_dir/html/$name.html -done - -for dot_file in $(find $script_dir -name '*.dot'); do - name=$(basename -s .dot $dot_file) - dot -Tpng $dot_file -o $script_dir/html/$name.png -done diff --git a/docs/dev/query/interpreter-class.png b/docs/dev/query/interpreter-class.png new file mode 100644 index 000000000..b36d223f3 Binary files /dev/null and b/docs/dev/query/interpreter-class.png differ diff --git a/docs/dev/quick-start.md b/docs/dev/quick-start.md index c7fc541ab..d62199917 100644 --- a/docs/dev/quick-start.md +++ b/docs/dev/quick-start.md @@ -17,7 +17,7 @@ On ArchLinux or Gentoo, you probably already know what to do. After installing `git`, you are now ready to fetch your own copy of Memgraph source code. Run the following command: - git clone https://phabricator.memgraph.io/diffusion/MG/memgraph.git + git clone https://github.com/memgraph/memgraph.git The above will create a `memgraph` directory and put all source code there. @@ -52,12 +52,13 @@ After installing the packages, issue the following commands: ### Compiling Memgraph is compiled using our own custom toolchain that can be obtained from -[Toolchain repository](https://s3-eu-west-1.amazonaws.com/deps.memgraph.io/toolchain). You should read -the `README.txt` file in the repository and install the apropriate toolchain -for your distribution. After you have installed the toolchain you should read -the instructions for the toolchain in the toolchain install directory -(`/opt/toolchain-vXYZ/README.md`) and install dependencies that are necessary -to run the toolchain. +[Toolchain +repository](https://s3-eu-west-1.amazonaws.com/deps.memgraph.io/toolchain). You +should read the `README.txt` file in the repository and install the apropriate +toolchain for your distribution. After you have installed the toolchain you +should read the instructions for the toolchain in the toolchain install +directory (`/opt/toolchain-vXYZ/README.md`) and install dependencies that are +necessary to run the toolchain. When you want to compile Memgraph you should activate the toolchain using the prepared toolchain activation script that is also described in the toolchain diff --git a/docs/dev/storage/accessors.md b/docs/dev/storage/v1/accessors.md similarity index 98% rename from docs/dev/storage/accessors.md rename to docs/dev/storage/v1/accessors.md index f6c37955b..2a8fac6ce 100644 --- a/docs/dev/storage/accessors.md +++ b/docs/dev/storage/v1/accessors.md @@ -38,7 +38,7 @@ interpretation code) should work with accessors. There is a `RecordAccessor` as a base class for `VertexAccessor` and `EdgeAccessor`. Following is an enumeration of their purpose. -### Data access +### Data Access The client interacts with Memgraph using the Cypher query language. That language has certain semantics which imply that multiple versions of the @@ -75,7 +75,7 @@ In distributed Memgraph accessors also contain a lot of the remote graph element handling logic. More info on that is available in the documentation for distributed. -### Deferred MVCC data lookup for Edges +### Deferred MVCC Data Lookup for Edges Vertices and edges are versioned using MVCC. This means that for each transaction an MVCC lookup needs to be done to determine which version @@ -100,7 +100,7 @@ working with that data directly whenever possible! Always consider the accessors to be the first go-to for interacting with data, especially when in the context of a transaction. -# Skiplist accessor +# Skiplist Accessor The term "accessor" is also used in the context of a skiplist. Every operation on a skiplist must be performed within on an diff --git a/docs/dev/storage/v1/contents.md b/docs/dev/storage/v1/contents.md new file mode 100644 index 000000000..e378d1379 --- /dev/null +++ b/docs/dev/storage/v1/contents.md @@ -0,0 +1,6 @@ +# Storage v1 + +* [Accessors](accessors.md) +* [Indexes](indexes.md) +* [Property Storage](property-storage.md) +* [Durability](durability.md) diff --git a/docs/dev/durability/wal.md b/docs/dev/storage/v1/durability.md similarity index 72% rename from docs/dev/durability/wal.md rename to docs/dev/storage/v1/durability.md index a64603f52..6648a3dc9 100644 --- a/docs/dev/durability/wal.md +++ b/docs/dev/storage/v1/durability.md @@ -1,4 +1,6 @@ -# Write-ahead logging +# Durability + +## Write-ahead Logging Typically WAL denotes the process of writing a "log" of database operations (state changes) to persistent storage before committing the @@ -53,3 +55,26 @@ inefficient) to recover the database from WAL only, provided all the WAL files created from DB start are available. It is not possible to recover partial database state (i.e. from some suffix of WAL files, without the preceding snapshot). + +## Snapshots + +A "snapshot" is a record of the current database state stored in permanent +storage. Note that the term "snapshot" is used also in the context of +the transaction engine to denote a set of running transactions. + +A snapshot is written to the file by Memgraph periodically if so +configured. The snapshot creation process is done within a transaction created +specifically for that purpose. The transaction is needed to ensure that +the stored state is internally consistent. + +The database state can be recovered from the snapshot during startup, if +so configured. This recovery works in conjunction with write-ahead log +recovery. + +A single snapshot contains all the data needed to recover a database. In +that sense snapshots are independent of each other and old snapshots can +be deleted once the new ones are safely stored, if it is not necessary +to revert the database to some older state. + +The exact format of the snapshot file is defined inline in the snapshot +creation code. diff --git a/docs/dev/storage/indexes.md b/docs/dev/storage/v1/indexes.md similarity index 98% rename from docs/dev/storage/indexes.md rename to docs/dev/storage/v1/indexes.md index 147f4448e..b623d13d3 100644 --- a/docs/dev/storage/indexes.md +++ b/docs/dev/storage/v1/indexes.md @@ -1,10 +1,10 @@ -# Label indexes +# Label Indexes These are unsorted indexes that contain all the vertices that have the label the indexes are for (one index per label). These kinds of indexes get automatically generated for each label used in the database. -### Updating the indexes +### Updating the Indexes Whenever something gets added to the record we update the index (add that record to index). We keep an index which might contain garbage (not relevant @@ -64,7 +64,7 @@ same order, with (record, vlist) pair already superseded by a newer record and as such won't be inserted while it's being deleted -### Querying the index +### Querying the Index We run through the index for the given label and do `vlist.find` operation for the current transaction, and check if the newest return record has that @@ -75,7 +75,7 @@ in the index are sorted by their `vlist*` and as such we can filter consecutive duplicate `vlist*` to only return one of those while still being able to create an iterator to index. -### Cleaning the index +### Cleaning the Index Cleaning the index is not as straightforward as it seems as a lot of garbage can accumulate, but it's hard to know when exactly can we delete some (record, diff --git a/docs/dev/storage/property-storage.md b/docs/dev/storage/v1/property-storage.md similarity index 95% rename from docs/dev/storage/property-storage.md rename to docs/dev/storage/v1/property-storage.md index 897c54ce7..947c4d8b3 100644 --- a/docs/dev/storage/property-storage.md +++ b/docs/dev/storage/v1/property-storage.md @@ -1,7 +1,7 @@ -# Property storage +# Property Storage Although the reader is probably familiar with properties in *Memgraph*, let's -briefly recap. +briefly recap. Both vertices and edges can store an arbitrary number of properties. Properties are, in essence, ordered pairs of property names and property values. Each @@ -21,9 +21,9 @@ must be one of the following types: Property values are modeled in a class conveniently called `PropertyValue`. -## Mapping between property names and property keys. +## Mapping Between Property Names and Property Keys. -Although users think of property names in terms of descriptive strings +Although users think of property names in terms of descriptive strings (e.g. "location" or "department"), *Memgraph* internally converts those names into property keys which are, essentially, unsigned 16-bit integers. @@ -49,7 +49,7 @@ An interface of `PropertyValueStore` is as follows: `clear` | Clears the storage. `iterator`| Provides an extension of `std::input_iterator` that iterates over storage. -## Storage location +## Storage Location By default, *Memgraph* is an in-memory database and all properties are therefore stored in working memory unless specified otherwise by the user. User has an @@ -63,12 +63,12 @@ property key has the following format: ``` |---location--|------id------| |-Memory|Disk-|-----2^15-----| -``` +``` In other words, the most significant bit determines the location where the -property will be stored. +property will be stored. -### In-memory storage +### In-memory Storage The underlying implementation of in-memory storage for the time being is `std::vector>`. Implementations of`at`, `set` @@ -76,7 +76,7 @@ and `erase` are linear in time. This implementation is arguably more efficient than `std::map` or `std::unordered_map` when the average number of properties of a record is relatively small (up to 10) which seems to be the case. -### On-disk storage +### On-disk Storage #### KVStore @@ -120,12 +120,12 @@ KVStore storage = ...; for (auto it = storage.begin("alpha"); it != storage.end("omega"); ++it) {} ``` -#### Data organization on disk +#### Data Organization on Disk Each `PropertyValueStore` instance can access a static `KVStore` object that can store `(key, value)` pairs on disk. The key of each property on disk consists of two parts — a unique identifier (unsigned 64-bit integer) of the current -record version (see mvcc docummentation for further clarification) and a +record version (see mvcc docummentation for further clarification) and a property key as described above. The actual value of the property is serialized into a bytestring using bolt `BaseEncoder`. Similarly, deserialization is performed by bolt `Decoder`. diff --git a/docs/dev/storage/v2/contents.md b/docs/dev/storage/v2/contents.md new file mode 100644 index 000000000..33496731e --- /dev/null +++ b/docs/dev/storage/v2/contents.md @@ -0,0 +1,3 @@ +# Storage v2 + +TODO(gitbuda): Write documentation. diff --git a/docs/dev/toolchain-bootstrap.md b/docs/dev/toolchain-bootstrap.md deleted file mode 100644 index a55177c26..000000000 --- a/docs/dev/toolchain-bootstrap.md +++ /dev/null @@ -1,152 +0,0 @@ -# Bootstrapping Compilation Toolchain for Memgraph - -Requirements: - - * libstdc++ shipped with gcc-6.3 or gcc-6.4 - * cmake >= 3.1, Debian Stretch uses cmake-3.7.2 - * clang-3.9 - -## Installing gcc-6.4 - -gcc-6.3 has a bug, so use the 6.4 version which is just a bugfix release. - -Requirements on CentOS 7: - - * wget - * make - * gcc (bootstrap) - * gcc-c++ (bootstrap) - * gmp-devel (bootstrap) - * mpfr-devel (bootstrap) - * libmpc-devel (bootstrap) - * zip - * perl - * dejagnu (testing) - * expect (testing) - * tcl (testing) - -``` -wget ftp://ftp.mpi-sb.mpg.de/pub/gnu/mirror/gcc.gnu.org/pub/gcc/releases/gcc-6.4.0/gcc-6.4.0.tar.gz -tar xf gcc-6.4.0.tar.gz -cd gcc-6.4.0 -mkdir build -cd build -../configure --disable-multilib --prefix= -make -# Testing -make -k check -make install -``` - -*Do not put gcc + libs on PATH* (unless you know what you are doing). - -## Installing cmake-3.7.2 - -Requirements on CentOS 7: - - * wget - * make - * gcc - * gcc-c++ - * ncurses-devel (optional, for ccmake) - -``` -wget https://cmake.org/files/v3.7/cmake-3.7.2.tar.gz -tar xf cmake-3.7.2.tar.gz -cd cmake-3.7.2.tar.gz -./bootstrap --prefix -make -make install -``` - -Put cmake on PATH (if appropriate) - -**Fix the bug in CpackRPM** - -`"/share/cmake-3.7/Modules/CPackRPM.cmake" line 2273 of 2442` - -The line - -``` -set(RPMBUILD_FLAGS "-bb") -``` -needs to be before - -``` -if(CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE OR NOT CPACK_RPM_USER_BINARY_SPECFILE) -``` - -It was probably accidentally placed after, and is fixed in later cmake -releases. - -## Installing clang-3.9 - -Requirements on CentOS 7: - - * wget - * make - * cmake - -``` -wget http://releases.llvm.org/3.9.1/llvm-3.9.1.src.tar.xz -tar xf llvm-3.9.1.src.tar.xz -mv llvm-3.9.1.src llvm - -wget http://releases.llvm.org/3.9.1/cfe-3.9.1.src.tar.xz -tar xf cfe-3.9.1.src.tar.xz -mv cfe-3.9.1.src llvm/tools/clang - -cd llvm -mkdir build -cd build -cmake -DCMAKE_BUILD_TYPE="Release" -DGCC_INSTALL_PREFIX= \ --DCMAKE_C_COMPILER= -DCMAKE_CXX_COMPILER= \ --DCMAKE_CXX_LINK_FLAGS="-L/lib64 -Wl,-rpath,/lib64" \ --DCMAKE_INSTALL_PREFIX= .. -make -# Testing -make check-clang -make install -``` - -Put clang on PATH (if appropriate) - -## Memgraph - -Requirements on CentOS 7: - - * libuuid-devel (antlr4) - * java-1.8.0-openjdk (antlr4) - * boost-static (too low version --- compile manually) - * rpm-build (RPM) - * python3 (tests, ...) - * which (required for rocksdb) - * sbcl (lisp C++ preprocessing) - -### Boost 1.62 - -``` -wget https://netix.dl.sourceforge.net/project/boost/boost/1.62.0/boost_1_62_0.tar.gz -tar xf boost_1_62_0.tar.gz -cd boost_1_62_0 -./bootstrap.sh --with-toolset=clang --with-libraries=iostreams,serialization --prefix= -./b2 -# Default installs to /usr/local/ -./b2 install -``` - -### Building Memgraph - -clang is *required* to be findable by cmake, i.e. it should be on PATH. -cmake isn't required to be on the path, since you run it manually, so can use -the full path to executable in order to run it. Obviously, it is convenient to -put cmake also on PATH. - -Building is done as explained in [Quick Start](quick-start.md), but each -`make` invocation needs to be prepended with: - -`LD_RUN_PATH=/lib64 make ...` - -### RPM - -Name format: `memgraph--..rpm` diff --git a/docs/dev/workflow.md b/docs/dev/workflow.md index 62f2839c3..8ba36f0f0 100644 --- a/docs/dev/workflow.md +++ b/docs/dev/workflow.md @@ -20,18 +20,12 @@ Finally, make git aware of your favourite editor: git config --global core.editor "vim" -## Phabricator +## Github All of the code in Memgraph needs to go through code review before it can be -accepted in the codebase. This is done through -[Phabricator](https://phacility.com/phabricator/). The command line tool for -interfacing with Phabricator is -[arcanist](https://phacility.com/phabricator/arcanist/). You should already -have it installed if you followed the steps in [Quick Start](quick-start.md). - -The only required setup is to go in the root of Memgraph's project and run: - - arc install-certificate +accepted in the codebase. This is done through [Github](https://github.com/). +You should already have it installed if you followed the steps in [Quick +Start](quick-start.md). ## Working on Your Feature Branch @@ -46,6 +40,7 @@ out of the `master` branch. For example, let's say you are adding static type checking to the query language compiler. You would create a branch called `mg_query_static_typing` with the following command: + # TODO(gitbuda): Discuss the naming conventions. git branch mg_query_static_typing To switch to that branch, type: @@ -98,34 +93,9 @@ possible. ### Sending Changes on a Review After finishing your work on your feature branch, you will want to send it on -code review. This is done through Arcanist. To do that, run the following -command: - - arc diff - -You will, once again, be presented with an editor where you need to describe -your whole work. `arc` will by default fill that description with your commit -messages. The title and summary of your work should also follow the -conventions of git messages as described above. If you followed the -guidelines, the message filled by `arc` should be fine. - -In addition to the message, you need to fill the `Reviewers:` line with -usernames of people who should do the code review. - -You changes will be visible on Phabricator as a so called "diff". You can find -the default view of active diffs -[here](https://phabricator.memgraph.io/differential/) - -### Updating Changes Based on Review - -When you get comments in the code review, you will want to make additional -modifications to your work. The same workflow as before applies: [Making and -Committing Changes](#making-and-committing-changes) - -After making those changes, send them back on code review: - - arc diff - +code review. This is done by pushing the branch to Github and creating a pull +request. You can find all PRs +[here](https://github.com/memgraph/memgraph/pulls). ### Updating From New Master @@ -152,26 +122,3 @@ your feature branch as if you just created and started working on that branch. You may continue with the usual workflow of [Making and Committing Changes](#making-and-committing-changes) and [Sending Changes on a Review](#sending-changes-on-a-review). - -### Sending Your Changes on Master Branch - -When your changes pass the code review, you are ready to integrate them in the -`master` branch. To do that, run the following command: - - arc land - -Arcanist will take care of obtaining the latest changes from `master` and -merging your changes on top. If the `land` was successful, Arcanist will -delete your local branch and you will be back on `master`. Continuing from the -examples above, the deleted branch would be `mg_query_static_typing`. - -This marks the completion of your changes, and you are ready to work on -something else. - -### Note For People Familiar With Git - -Since Arcanist takes care of merging your git commits and pushing them on -`master`, you should *never* have to call `git merge` and `git push`. If you -find yourself typing those commands, check that you are doing the right thing. -The most common mistake is to use `git merge` instead of `git rebase` for the -case described in [Updating From New Master](#updating-from-new-master). diff --git a/docs/doxygen/README.md b/docs/doxygen/README.md index 082368097..a571b02b3 100644 --- a/docs/doxygen/README.md +++ b/docs/doxygen/README.md @@ -1,7 +1,6 @@ # Memgraph Code Documentation -IMPORTANT: auto-generated (run doxygen Doxyfile in the project root) +IMPORTANT: Auto-generated (run doxygen Doxyfile in the project root). -* HTML - just open docs/doxygen/html/index.html - -* Latex - run make inside docs/doxygen/latex +* HTML - Open docs/doxygen/html/index.html. +* Latex - Run make inside docs/doxygen/latex. diff --git a/Doxylogo.png b/docs/doxygen/memgraph_logo.png similarity index 100% rename from Doxylogo.png rename to docs/doxygen/memgraph_logo.png diff --git a/docs/feature_spec/contents.md b/docs/feature_spec/contents.md new file mode 100644 index 000000000..c700a401c --- /dev/null +++ b/docs/feature_spec/contents.md @@ -0,0 +1,3 @@ +# Feature Specifications + +* [Python Query Modules](python-query-modules.md) diff --git a/release/README.md b/release/README.md index 63fe8aa99..920e7042a 100644 --- a/release/README.md +++ b/release/README.md @@ -23,12 +23,12 @@ scenarios: To release a new major.minor release of Memgraph you should execute the following steps: - 1. Land all diffs that must be in the new release - 2. Document all changes in `CHANGELOG.md` and land them + 1. Merge all PRs that must be in the new release + 2. Document all changes in `CHANGELOG.md` and merge them 3. From the `master` branch, create a branch named `release/X.Y` and push it to `origin` - 4. Create the release packages triggering a `mg-master-release-branch-test` - using branch `release/X.Y` on Apollo + 4. Create the release packages triggering a `Release {{Operating System}}` + workflow using branch `release/X.Y` on Github Actions 5. Enjoy To release a new patch release in an existing major.minor series you should @@ -38,6 +38,6 @@ execute the following steps: 3. Document all changes in `CHANGELOG.md` and commit them 4. Edit the root `CMakeLists.txt` and set `MEMGRAPH_OVERRIDE_VERSION` to `X.Y.patch` and commit the change - 5. Create the release packages triggering a `mg-master-release-branch-test` - using branch `release/X.Y` on Apollo + 5. Create the release packages triggering a `Release {{Operating System}}` + workflow using branch `release/X.Y` on Github Actions 6. Enjoy