Go to file
Folling 48e76e960a
update sqlitecpp
2024-02-15 23:43:25 +01:00
docs finalise interface & documentation 2023-11-06 13:18:01 +01:00
include fixup missing ikarus_ prefix for error_info_name 2024-02-12 15:34:37 +01:00
src update sqlitecpp 2024-02-12 16:45:39 +01:00
vendor update sqlitecpp 2024-02-15 23:43:25 +01:00
.clang-format change error system & function signatures 2024-01-02 15:30:18 +01:00
.clang-tidy add src/ikarus subdir and make names unique for objects per scope 2024-01-30 09:31:08 +01:00
.gitignore a new beginning 2023-08-22 00:27:22 +02:00
.gitmodules improve cmake setup 2024-02-15 22:04:37 +01:00
CMakeLists.txt improve cmake setup 2024-02-15 22:04:37 +01:00
LICENSE.md finalise interface & documentation 2023-11-06 13:18:01 +01:00
README.md change error system & function signatures 2024-01-02 15:30:18 +01:00

README.md

Data Longevity

All data returned by libikarus is ephemeral and only represents the state of the project at the time of the request. A snapshot if you will. One must not rely on it representing the actual state of the project at any given time. The data is simply copied from the underlying data sources and returned to the caller.

No mechanisms are provided to avoid race conditions. libikarus itself should only be used in a single-threaded context. However, nothing breaks if you do use it in a multithreaded context, that is, libikarus is threadsafe. You just cannot rely on the data being consistent. This goes especially for inter-process access to the same project.