You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: CONTRIBUTING.md
+3-3
Original file line number
Diff line number
Diff line change
@@ -37,7 +37,7 @@ The local build must complete successfully before you open a pull request.
37
37
38
38
## Importing documentation
39
39
40
-
This repository contains documentation about Kurrent and its client SDKs. The documentation for EventStoreDB, including its HTTP API, is imported from the respective repositories on build. To import the documentation manually, run:
40
+
This repository contains documentation about Kurrent and its client SDKs. The documentation for KurrentDB, including its HTTP API, is imported from the respective repositories on build. To import the documentation manually, run:
41
41
42
42
```bash
43
43
pnpm run import
@@ -56,8 +56,8 @@ The documentation sources are located in the `/docs` directory. The `/docs/.vuep
56
56
Other directors inside `/docs` include:
57
57
-`clients`: documentation for current and legacy clients
58
58
-`cloud`: Kurrent Cloud documentation
59
-
-`server`: EventStoreDB documentation imported from the server repository
60
-
-`http-api`: EventStoreDB HTTP API documentation imported from the server repository
59
+
-`server`: KurrentDB documentation imported from the server repository
60
+
-`http-api`: KurrentDB HTTP API documentation imported from the server repository
61
61
-`samples`: imported code samples for the client SDKs, server, and HTTP API
62
62
63
63
Directories with imported code like `server`, `http-api`, and `samples` are generated on build and should not be edited manually. They are also listed in `.gitignore` and won't be committed to the repository.
Copy file name to clipboardexpand all lines: README.md
+5-5
Original file line number
Diff line number
Diff line change
@@ -1,22 +1,22 @@
1
-
# EventStoreDB documentation
1
+
# KurrentDB documentation
2
2
3
-
EventStoreDB is an open-source, functional database with Complex Event Processing in JavaScript.
3
+
KurrentDB is an open-source, functional database with Complex Event Processing in JavaScript.
4
4
5
-
This repository maintains documentation for EventStoreDB (imported from the server repository on build), Kurrent Cloud, client SDKs, and other tools and product provided by Kurrent.
5
+
This repository maintains documentation for KurrentDB (imported from the server repository on build), Kurrent Cloud, client SDKs, and other tools and product provided by Kurrent.
6
6
7
7
## Contributing
8
8
9
9
Feel free to [create a GitHub](https://github.com/EventStore/documentation/issues/new) issue if you have any questions or request for more explanation or samples.
10
10
11
11
We're open to any contribution. If you noticed some inconsistency, missing piece, or you'd like to extend existing docs - we'll be happy to [get your Pull Request](https://github.com/EventStore/documentation/compare).
12
12
13
-
Note that EventStoreDB documentation is located in the [server repository](https://github.com/EventStore/EventStore). Open issues and PRs for server documentation in there.
13
+
Note that KurrentDB documentation is located in the [server repository](https://github.com/EventStore/EventStore). Open issues and PRs for server documentation in there.
14
14
15
15
Please make sure to follow the [contribution guidelines](CONTRIBUTING.md). It contains detailed information on how to contribute to the documentation.
title: "This documentation is for the legacy TCP client",
14
-
content: "This client is no longer supported because newer versions of EventStoreDB only support gRPC-based client protocol. Please use the latest client libraries.",
14
+
content: "This client is no longer supported because newer versions of KurrentDB only support gRPC-based client protocol. Please use the latest client libraries.",
Copy file name to clipboardexpand all lines: docs/clients/grpc/appending-events.md
+9-9
Original file line number
Diff line number
Diff line change
@@ -4,15 +4,15 @@ order: 2
4
4
5
5
# Appending events
6
6
7
-
When you start working with EventStoreDB, it is empty. The first meaningful operation is to add one or more events to the database using one of the available client SDKs.
7
+
When you start working with KurrentDB, it is empty. The first meaningful operation is to add one or more events to the database using one of the available client SDKs.
8
8
9
9
::: tip
10
10
Check the [Getting Started](getting-started.md) guide to learn how to configure and use the client SDK.
11
11
:::
12
12
13
13
## Append your first event
14
14
15
-
The simplest way to append an event to EventStoreDB is to create an `EventData` object and call `AppendToStream` method.
15
+
The simplest way to append an event to KurrentDB is to create an `EventData` object and call `AppendToStream` method.
@@ -26,11 +26,11 @@ If you are new to Event Sourcing, please study the [Handling concurrency](#handl
26
26
27
27
## Working with EventData
28
28
29
-
Events appended to EventStoreDB must be wrapped in an `EventData` object. This allows you to specify the event's content, the type of event, and whether it's in JSON format. In its simplest form, you need three arguments: **eventId**, **type**, and **data**.
29
+
Events appended to KurrentDB must be wrapped in an `EventData` object. This allows you to specify the event's content, the type of event, and whether it's in JSON format. In its simplest form, you need three arguments: **eventId**, **type**, and **data**.
30
30
31
31
### eventId
32
32
33
-
This takes the format of a `Uuid` and is used to uniquely identify the event you are trying to append. If two events with the same `Uuid` are appended to the same stream in quick succession, EventStoreDB will only append one of the events to the stream.
33
+
This takes the format of a `Uuid` and is used to uniquely identify the event you are trying to append. If two events with the same `Uuid` are appended to the same stream in quick succession, KurrentDB will only append one of the events to the stream.
34
34
35
35
For example, the following code will only append a single event:
36
36
@@ -46,19 +46,19 @@ It is common to see the explicit event code type name used as the type as it mak
46
46
47
47
### data
48
48
49
-
Representation of your event data. It is recommended that you store your events as JSON objects. This allows you to take advantage of all of EventStoreDB's functionality, such as projections. That said, you can save events using whatever format suits your workflow. Eventually, the data will be stored as encoded bytes.
49
+
Representation of your event data. It is recommended that you store your events as JSON objects. This allows you to take advantage of all of KurrentDB's functionality, such as projections. That said, you can save events using whatever format suits your workflow. Eventually, the data will be stored as encoded bytes.
50
50
51
51
### metadata
52
52
53
-
Storing additional information alongside your event that is part of the event itself is standard practice. This can be correlation IDs, timestamps, access information, etc. EventStoreDB allows you to store a separate byte array containing this information to keep it separate.
53
+
Storing additional information alongside your event that is part of the event itself is standard practice. This can be correlation IDs, timestamps, access information, etc. KurrentDB allows you to store a separate byte array containing this information to keep it separate.
54
54
55
55
### isJson
56
56
57
-
Simple boolean field to tell EventStoreDB if the event is stored as json, true by default.
57
+
Simple boolean field to tell KurrentDB if the event is stored as json, true by default.
58
58
59
59
## Handling concurrency
60
60
61
-
When appending events to a stream, you can supply a *stream state* or *stream revision*. Your client uses this to inform EventStoreDB of the state or version you expect the stream to be in when appending an event. If the stream isn't in that state, an exception will be thrown.
61
+
When appending events to a stream, you can supply a *stream state* or *stream revision*. Your client uses this to inform KurrentDB of the state or version you expect the stream to be in when appending an event. If the stream isn't in that state, an exception will be thrown.
62
62
63
63
For example, if you try to append the same record twice, expecting both times that the stream doesn't exist, you will get an exception on the second:
64
64
@@ -69,7 +69,7 @@ There are three available stream states:
69
69
-`NoStream`
70
70
-`StreamExists`
71
71
72
-
This check can be used to implement optimistic concurrency. When retrieving a stream from EventStoreDB, note the current version number. When you save it back, you can determine if somebody else has modified the record in the meantime.
72
+
This check can be used to implement optimistic concurrency. When retrieving a stream from KurrentDB, note the current version number. When you save it back, you can determine if somebody else has modified the record in the meantime.
Copy file name to clipboardexpand all lines: docs/clients/grpc/delete-stream.md
+4-4
Original file line number
Diff line number
Diff line change
@@ -1,11 +1,11 @@
1
1
# Deleting events
2
2
3
-
In EventStoreDB, you can delete events and streams either partially or completely. Settings like $maxAge and $maxCount help control how long events are kept or how many events are stored in a stream, but they won't delete the entire stream.
4
-
When you need to fully remove a stream, EventStoreDB offers two options: Soft Delete and Hard Delete.
3
+
In KurrentDB, you can delete events and streams either partially or completely. Settings like $maxAge and $maxCount help control how long events are kept or how many events are stored in a stream, but they won't delete the entire stream.
4
+
When you need to fully remove a stream, KurrentDB offers two options: Soft Delete and Hard Delete.
5
5
6
6
## Soft delete
7
7
8
-
Soft delete in EventStoreDB allows you to mark a stream for deletion without completely removing it, so you can still add new events later. While you can do this through the UI, using code is often better for automating the process,
8
+
Soft delete in KurrentDB allows you to mark a stream for deletion without completely removing it, so you can still add new events later. While you can do this through the UI, using code is often better for automating the process,
9
9
handling many streams at once, or including custom rules. Code is especially helpful for large-scale deletions or when you need to integrate soft deletes into other workflows.
10
10
11
11
::: tabs#lang
@@ -54,7 +54,7 @@ The stream can still be reopened by appending new events.
54
54
55
55
## Hard delete
56
56
57
-
Hard delete in EventStoreDB permanently removes a stream and its events. While you can use the HTTP API, code is often better for automating the process, managing multiple streams, and ensuring precise control. Code is especially useful when you need to integrate hard delete into larger workflows or apply specific conditions. Note that when a stream is hard deleted, you cannot reuse the stream name, it will raise an exception if you try to append to it again.
57
+
Hard delete in KurrentDB permanently removes a stream and its events. While you can use the HTTP API, code is often better for automating the process, managing multiple streams, and ensuring precise control. Code is especially useful when you need to integrate hard delete into larger workflows or apply specific conditions. Note that when a stream is hard deleted, you cannot reuse the stream name, it will raise an exception if you try to append to it again.
0 commit comments