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: modules/ROOT/pages/_partials/sync-api/sync-function-api-expiry.adoc
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -69,7 +69,7 @@ This expiration time is not propagated when the document is replicated.
69
69
The purge of the document does not cause it to be deleted on any other database.
70
70
71
71
=== Inspect a Document Expiry Value
72
-
You can retrieve a document's expiration time, as it is returned in the response of GET xref:{rest-api--page}##/document/get__db___doc_[+/\{db/\{doc}] use `show_exp=true` as the querystring.
72
+
You can retrieve a document's expiration time, as it is returned in the response of GET xref:{rest-api--page}#/document/get__db___doc_[+/{db}/{doc}+] using `show_exp=true` as the querystring.
For other providers we recommend to use Custom Authentication or OpenID Connect.
95
95
@@ -104,7 +104,7 @@ The last request creates a session.
104
104
105
105
image::custom-auth-flow.png[]
106
106
107
-
Given a user that has already been created, a new session for that user can be created on the Admin {rest-api-admin--pfx}#/session/post\__db___session[POST /+\{db}+/_session] endpoint.
107
+
Given a user that has already been created, a new session for that user can be created on the Admin {rest-api-admin--pfx}#/session/post\__db___session[POST /+{db}+/_session] endpoint.
108
108
109
109
[source,bash]
110
110
----
@@ -143,7 +143,7 @@ There are two implementation methods available with OpenID Connect:
143
143
144
144
<<implicit-flow>>::
145
145
With this method, the retrieval of the ID token takes place on the device.
146
-
You can then create a user session using the POST `+/\{tkn-db}/_session+` endpoint on the Public REST API with the ID token.
146
+
You can then create a user session using the POST `+/{db}/_session+` endpoint on the Public REST API with the ID token.
147
147
<<authorization-code-flow>>::
148
148
This method relies on {sgw} to retrieve the ID token.
149
149
@@ -205,7 +205,7 @@ By doing this, the application can then use the token to create a {sgw} session.
205
205
image::client-auth.png[]
206
206
207
207
. The Google SignIn SDK prompts the user to login and if successful it returns an ID token to the application.
208
-
. The ID token is used to create a {sgw} session by sending a POST `+/\{tkn-db}/_session+` request.
208
+
. The ID token is used to create a {sgw} session by sending a POST `+/{db}/_session+` request.
209
209
. {sgw} returns a cookie session in the response header.
210
210
. The {sgw} cookie session is used on the replicator object.
Copy file name to clipboardExpand all lines: modules/ROOT/pages/changes-feed.adoc
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -41,7 +41,7 @@ For instance if you have a channel called "needs-email" you could have a bot tha
41
41
== Endpoint
42
42
43
43
44
-
The changes feed API is a REST API endpoint (xref:rest-api.adoc#/database/get\__db___changes[`+/\{tkn-db}/_changes+`]) that returns a sorted list of changes made to documents in the database.
44
+
The changes feed API is a REST API endpoint (xref:rest-api.adoc#/database/get\__db___changes[`+/{db}/_changes+`]) that returns a sorted list of changes made to documents in the database.
45
45
It permits applications to implement business logic that reacts to changes in documents.
Copy file name to clipboardExpand all lines: modules/ROOT/pages/database-management.adoc
+8-8Lines changed: 8 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -93,8 +93,8 @@ Set the expiry time to be sufficient to allow for all other devices to sync and
93
93
|Tombstones are automatically purged from the bucket based on the server's metadata purge interval.
94
94
95
95
|Manual
96
-
|Tombstones can be manually removed via Sync Gateway's {rest-api-admin--pfx}#/document/post\__db___purge[+/\{tkn-db}/_purge+] endpoint, or deleting documents directly in the bucket.
97
-
|Tombstones can be manually removed via Sync Gateway's {rest-api-admin--pfx}#/document/post\__db___purge[+/\{tkn-db}/_purge+] endpoint.
96
+
|Tombstones can be manually removed via Sync Gateway's {rest-api-admin--pfx}#/document/post\__db___purge[+/{db}/_purge+] endpoint, or deleting documents directly in the bucket.
97
+
|Tombstones can be manually removed via Sync Gateway's {rest-api-admin--pfx}#/document/post\__db___purge[+/{db}/_purge+] endpoint.
98
98
|===
99
99
100
100
Purging of tombstones is also required on Couchbase Lite.
@@ -123,7 +123,7 @@ Purged On
123
123
| Couchbase Server
124
124
| Restarting Sync Gateway will flush the cache
125
125
| * Restarting Sync Gateway will flush the cache
126
-
* Running the {rest-api-admin--pfx}#/database/post\__db___compact[+/\{tkn-db}/_compact+] endpoint will remove purged tombstones from the channel cache {fn-211}
126
+
* Running the {rest-api-admin--pfx}#/database/post\__db___compact[+/{db}/_compact+] endpoint will remove purged tombstones from the channel cache {fn-211}
127
127
128
128
| Sync Gateway
129
129
a| * Restarting Sync Gateway will flush the cache.
@@ -166,7 +166,7 @@ To update the Sync Function and fully resync, you are recommended to follow the
166
166
NOTE: This is an expensive operation because it requires every document in the database to be processed by the new function.
167
167
168
168
The database can accept no requests until this process is complete because no user's full access privileges are known until all documents have been scanned.
169
-
Therefore, the Sync Function update will result in application downtime whilst teh database is offline (that is, between the call to the `+/{tkn-db}/_offline+` and `+/{tkn-db}/_online+` endpoints in <<steps-to-resync>>.
169
+
Therefore, the Sync Function update will result in application downtime whilst the database is offline (that is, between the call to the `+/{db}/_offline+` and `+/{db}/_online+` endpoints in <<steps-to-resync>>.
170
170
171
171
172
172
[#steps-to-resync]
@@ -176,15 +176,15 @@ Therefore, the Sync Function update will result in application downtime whilst t
@@ -210,7 +210,7 @@ Running a resync operation does not revoke access to that document.
210
210
If you need to ensure access to the database during the update, you can create a read-only backup of the Sync Gateway's bucket beforehand, then run a secondary Sync Gateway on the backup bucket, in read-only mode.
211
211
After the update is complete, switch to the main Gateway and bucket.
212
212
213
-
In a clustered environment with multiple Sync Gateway instances sharing the load, all the instances need to share the same configuration, so they all need to be taken offline either by stopping the process or taking them offline using the {rest-api-admin--pfx}#/Database_Management/post\__db___offline[+/{tkn-db}/_offline+] endpoint.
213
+
In a clustered environment with multiple Sync Gateway instances sharing the load, all the instances need to share the same configuration, so they all need to be taken offline either by stopping the process or taking them offline using the {rest-api-admin--pfx}#/Database_Management/post\__db___offline[+/{db}/_offline+] endpoint.
214
214
After the configuration is updated, *one* instance should be brought up so it can update the database--if more than one is running at this time, they'll conflict with each other.
215
215
After the first instance finishes opening the database, the others can be started.
Copy file name to clipboardExpand all lines: modules/ROOT/pages/database-offline.adoc
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -40,13 +40,13 @@ Specific uses for the database offline/online functionality include:
40
40
41
41
== Actions
42
42
43
-
* Taking a database offline: {rest-api-admin--pfx}#/database/post\__db___offline[POST /+\{db}+/_offline]
44
-
* Taking a database online: {rest-api-admin--pfx}#/database/post\__db___online[POST /+\{db}+/_online]
43
+
* Taking a database offline: {rest-api-admin--pfx}#/database/post\__db___offline[POST /+{db}+/_offline]
44
+
* Taking a database online: {rest-api-admin--pfx}#/database/post\__db___online[POST /+{db}+/_online]
45
45
46
46
By default, when Sync Gateway starts, it brings all databases that are defined in the configuration file online.
47
47
To keep a database offline when Sync Gateway starts, you can add the `offline` configuration property to the database configuration properties -- see {rest-api-admin--xref--database-configuration}.
48
48
49
-
Later, to bring the database online, you can use the `+POST /\{tkn-db}/_online+` Admin REST API request.
49
+
Later, to bring the database online, you can use the `+POST /{db}/_online+` Admin REST API request.
Copy file name to clipboardExpand all lines: modules/ROOT/pages/get-started-verify-install.adoc
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -450,9 +450,9 @@ Assuming the delete worked you should see the following response:
450
450
451
451
To verify that document changes have been replicated, you can:
452
452
453
-
* Monitor the {sgw} revision number returned by the database endpoint (xref:{rest-api--page}#/database/get\__db__[GET /\{tkn-db}/]).
453
+
* Monitor the {sgw} revision number returned by the database endpoint (xref:{rest-api--page}#/database/get\__db__[GET /\{db}/]).
454
454
The revision number increments for every change that happens on the {sgw} database.
455
-
* Query a document by ID on the {sgw} REST API as shown in <<lbl-check-cbs>>. Use (xref:{rest-api--page}#/document/get\__db___doc_[GET /\{tkn-db}/\{id}]) -- see: {rest-api-access--xref} for more.
455
+
* Query a document by ID on the {sgw} REST API as shown in <<lbl-check-cbs>>. Use (xref:{rest-api--page}#/document/get\__db___doc_[GET /\{db}/\{id}]) -- see: {rest-api-access--xref} for more.
456
456
* Query a document from the Query Workbench on the {cbs} Console.
Copy file name to clipboardExpand all lines: modules/ROOT/pages/managing-tombstones.adoc
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -163,8 +163,8 @@ Set the expiry time to be sufficient to allow for all other devices to sync and
163
163
|Tombstones are automatically purged from the bucket based on the server's metadata purge interval.
164
164
165
165
|Manual
166
-
|Tombstones can be manually removed via Sync Gateway's {rest-api-admin--pfx}#/document/post\__db___purge[+/\{tkn-db}/_purge+] endpoint, or deleting documents directly in the bucket.
167
-
|Tombstones can be manually removed via Sync Gateway's {rest-api-admin--pfx}#/document/post\__db___purge[+/\{tkn-db}/_purge+] endpoint.
166
+
|Tombstones can be manually removed via Sync Gateway's {rest-api-admin--pfx}#/document/post\__db___purge[+/{db}/_purge+] endpoint, or deleting documents directly in the bucket.
167
+
|Tombstones can be manually removed via Sync Gateway's {rest-api-admin--pfx}#/document/post\__db___purge[+/{db}/_purge+] endpoint.
168
168
|===
169
169
170
170
Purging of tombstones is also required on Couchbase Lite.
@@ -193,7 +193,7 @@ Purged On
193
193
| Couchbase Server
194
194
| Restarting Sync Gateway will flush the cache
195
195
| * Restarting Sync Gateway will flush the cache
196
-
* Running the {rest-api-admin--pfx}#/database/post\__db___compact[+/\{tkn-db}/_compact+] endpoint will remove purged tombstones from the channel cache {fn-211}
196
+
* Running the {rest-api-admin--pfx}#/database/post\__db___compact[+/{db}/_compact+] endpoint will remove purged tombstones from the channel cache {fn-211}
197
197
198
198
| Sync Gateway
199
199
a| * Restarting Sync Gateway will flush the cache.
@@ -50,7 +49,7 @@ To update the Sync Function and fully resync, you are recommended to follow the
50
49
NOTE: This is an expensive operation because it requires every document in the database to be processed by the new function.
51
50
52
51
The database can accept no requests until resync is complete because no user's full access privileges are known until all documents have been scanned.
53
-
Therefore, the Sync Function update will result in application downtime whilst the database is offline (that is, between the call to the `/{tkn-db}/_offline` and `/{tkn-db}/_online` endpoints in <<steps-to-resync>>.
52
+
Therefore, the Sync Function update will result in application downtime whilst the database is offline (that is, between the call to the `+/{db}/_offline+` and `+/{db}/_online+` endpoints in <<steps-to-resync>>.
54
53
55
54
You won't need to run the resync operation, if either:
56
55
@@ -66,15 +65,15 @@ You won't need to run the resync operation, if either:
@@ -84,7 +83,7 @@ Use this Admin REST API endpoint:
84
83
Resync is run asynchronously.
85
84
Its status can be monitored using {resync_api_get}.
86
85
87
-
Be sure to take the database offline using {rest-api-admin--pfx}#/Database_Management/post\__db___offline[/{tkn-db}/_offline]
86
+
Be sure to take the database offline using {rest-api-admin--pfx}#/Database_Management/post\__db___offline[+/{db}/_offline+]
88
87
89
88
=== Resync Context
90
89
@@ -107,7 +106,7 @@ Once you detect the resync is complete, switch back to the main Sync Gateway and
107
106
=== Updating Clusters
108
107
109
108
In a clustered environment with multiple Sync Gateway instances sharing the load, all the instances need to share the same configuration.
110
-
To ensure this happens, you must taken all instances offline using the {rest-api-admin--pfx}#/Database_Management/post\__db___offline[/{tkn-db}/_offline] endpoint.
109
+
To ensure this happens, you must taken all instances offline using the {rest-api-admin--pfx}#/Database_Management/post\__db___offline[+/{db}/_offline+] endpoint.
111
110
112
111
After the configuration is updated, *one* instance should be brought up so it can update the database--if more than one is running at this time, they'll conflict with each other.
113
112
After the first instance finishes opening the database, the others can be started.
0 commit comments