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: clients/google-api-services-firestore/v1/2.0.0/com/google/api/services/firestore/v1/model/GoogleFirestoreAdminV1Database.java
+9-9Lines changed: 9 additions & 9 deletions
Original file line number
Diff line number
Diff line change
@@ -133,7 +133,7 @@ public final class GoogleFirestoreAdminV1Database extends com.google.api.client.
133
133
privatejava.lang.StringkeyPrefix;
134
134
135
135
/**
136
-
* The location of the database. Available locations are listed at
136
+
* Required. The location of the database. Available locations are listed at
Copy file name to clipboardExpand all lines: clients/google-api-services-firestore/v1/2.0.0/com/google/api/services/firestore/v1/model/StructuredQuery.java
+48-30Lines changed: 48 additions & 30 deletions
Original file line number
Diff line number
Diff line change
@@ -79,16 +79,22 @@ public final class StructuredQuery extends com.google.api.client.json.GenericJso
79
79
privatejava.lang.Integeroffset;
80
80
81
81
/**
82
-
* The order to apply to the query results. Firestore allows callers to provide a full ordering, a
83
-
* partial ordering, or no ordering at all. In all cases, Firestore guarantees a stable ordering
84
-
* through the following rules: * The `order_by` is required to reference all fields used with an
85
-
* inequality filter. * All fields that are required to be in the `order_by` but are not already
86
-
* present are appended in lexicographical ordering of the field name. * If an order on `__name__`
87
-
* is not specified, it is appended by default. Fields are appended with the same sort direction
88
-
* as the last order specified, or 'ASCENDING' if no order was specified. For example: * `ORDER BY
89
-
* a` becomes `ORDER BY a ASC, __name__ ASC` * `ORDER BY a DESC` becomes `ORDER BY a DESC,
90
-
* __name__ DESC` * `WHERE a > 1` becomes `WHERE a > 1 ORDER BY a ASC, __name__ ASC` * `WHERE
91
-
* __name__ > ... AND a > 1` becomes `WHERE __name__ > ... AND a > 1 ORDER BY a ASC, __name__ ASC`
82
+
* The order to apply to the query results. Callers can provide a full ordering, a partial
83
+
* ordering, or no ordering at all. While Firestore will always respect the provided order, the
84
+
* behavior for queries without a full ordering is different per database edition: In Standard
85
+
* edition, Firestore guarantees a stable ordering through the following rules: * The `order_by`
86
+
* is required to reference all fields used with an inequality filter. * All fields that are
87
+
* required to be in the `order_by` but are not already present are appended in lexicographical
88
+
* ordering of the field name. * If an order on `__name__` is not specified, it is appended by
89
+
* default. Fields are appended with the same sort direction as the last order specified, or
90
+
* 'ASCENDING' if no order was specified. For example: * `ORDER BY a` becomes `ORDER BY a ASC,
91
+
* __name__ ASC` * `ORDER BY a DESC` becomes `ORDER BY a DESC, __name__ DESC` * `WHERE a > 1`
92
+
* becomes `WHERE a > 1 ORDER BY a ASC, __name__ ASC` * `WHERE __name__ > ... AND a > 1` becomes
93
+
* `WHERE __name__ > ... AND a > 1 ORDER BY a ASC, __name__ ASC` In Enterprise edition, Firestore
94
+
* does not guarantee a stable ordering. Instead it will pick the most efficient ordering based on
95
+
* the indexes available at the time of query execution. This will result in a different ordering
96
+
* for queries that are otherwise identical. To ensure a stable ordering, always include a unique
97
+
* field in the `order_by` clause, such as `__name__`.
92
98
* The value may be {@code null}.
93
99
*/
94
100
@com.google.api.client.util.Key
@@ -233,33 +239,45 @@ public StructuredQuery setOffset(java.lang.Integer offset) {
233
239
}
234
240
235
241
/**
236
-
* The order to apply to the query results. Firestore allows callers to provide a full ordering, a
237
-
* partial ordering, or no ordering at all. In all cases, Firestore guarantees a stable ordering
238
-
* through the following rules: * The `order_by` is required to reference all fields used with an
239
-
* inequality filter. * All fields that are required to be in the `order_by` but are not already
240
-
* present are appended in lexicographical ordering of the field name. * If an order on `__name__`
241
-
* is not specified, it is appended by default. Fields are appended with the same sort direction
242
-
* as the last order specified, or 'ASCENDING' if no order was specified. For example: * `ORDER BY
243
-
* a` becomes `ORDER BY a ASC, __name__ ASC` * `ORDER BY a DESC` becomes `ORDER BY a DESC,
244
-
* __name__ DESC` * `WHERE a > 1` becomes `WHERE a > 1 ORDER BY a ASC, __name__ ASC` * `WHERE
245
-
* __name__ > ... AND a > 1` becomes `WHERE __name__ > ... AND a > 1 ORDER BY a ASC, __name__ ASC`
242
+
* The order to apply to the query results. Callers can provide a full ordering, a partial
243
+
* ordering, or no ordering at all. While Firestore will always respect the provided order, the
244
+
* behavior for queries without a full ordering is different per database edition: In Standard
245
+
* edition, Firestore guarantees a stable ordering through the following rules: * The `order_by`
246
+
* is required to reference all fields used with an inequality filter. * All fields that are
247
+
* required to be in the `order_by` but are not already present are appended in lexicographical
248
+
* ordering of the field name. * If an order on `__name__` is not specified, it is appended by
249
+
* default. Fields are appended with the same sort direction as the last order specified, or
250
+
* 'ASCENDING' if no order was specified. For example: * `ORDER BY a` becomes `ORDER BY a ASC,
251
+
* __name__ ASC` * `ORDER BY a DESC` becomes `ORDER BY a DESC, __name__ DESC` * `WHERE a > 1`
252
+
* becomes `WHERE a > 1 ORDER BY a ASC, __name__ ASC` * `WHERE __name__ > ... AND a > 1` becomes
253
+
* `WHERE __name__ > ... AND a > 1 ORDER BY a ASC, __name__ ASC` In Enterprise edition, Firestore
254
+
* does not guarantee a stable ordering. Instead it will pick the most efficient ordering based on
255
+
* the indexes available at the time of query execution. This will result in a different ordering
256
+
* for queries that are otherwise identical. To ensure a stable ordering, always include a unique
257
+
* field in the `order_by` clause, such as `__name__`.
246
258
* @return value or {@code null} for none
247
259
*/
248
260
publicjava.util.List<Order> getOrderBy() {
249
261
returnorderBy;
250
262
}
251
263
252
264
/**
253
-
* The order to apply to the query results. Firestore allows callers to provide a full ordering, a
254
-
* partial ordering, or no ordering at all. In all cases, Firestore guarantees a stable ordering
255
-
* through the following rules: * The `order_by` is required to reference all fields used with an
256
-
* inequality filter. * All fields that are required to be in the `order_by` but are not already
257
-
* present are appended in lexicographical ordering of the field name. * If an order on `__name__`
258
-
* is not specified, it is appended by default. Fields are appended with the same sort direction
259
-
* as the last order specified, or 'ASCENDING' if no order was specified. For example: * `ORDER BY
260
-
* a` becomes `ORDER BY a ASC, __name__ ASC` * `ORDER BY a DESC` becomes `ORDER BY a DESC,
261
-
* __name__ DESC` * `WHERE a > 1` becomes `WHERE a > 1 ORDER BY a ASC, __name__ ASC` * `WHERE
262
-
* __name__ > ... AND a > 1` becomes `WHERE __name__ > ... AND a > 1 ORDER BY a ASC, __name__ ASC`
265
+
* The order to apply to the query results. Callers can provide a full ordering, a partial
266
+
* ordering, or no ordering at all. While Firestore will always respect the provided order, the
267
+
* behavior for queries without a full ordering is different per database edition: In Standard
268
+
* edition, Firestore guarantees a stable ordering through the following rules: * The `order_by`
269
+
* is required to reference all fields used with an inequality filter. * All fields that are
270
+
* required to be in the `order_by` but are not already present are appended in lexicographical
271
+
* ordering of the field name. * If an order on `__name__` is not specified, it is appended by
272
+
* default. Fields are appended with the same sort direction as the last order specified, or
273
+
* 'ASCENDING' if no order was specified. For example: * `ORDER BY a` becomes `ORDER BY a ASC,
274
+
* __name__ ASC` * `ORDER BY a DESC` becomes `ORDER BY a DESC, __name__ DESC` * `WHERE a > 1`
275
+
* becomes `WHERE a > 1 ORDER BY a ASC, __name__ ASC` * `WHERE __name__ > ... AND a > 1` becomes
276
+
* `WHERE __name__ > ... AND a > 1 ORDER BY a ASC, __name__ ASC` In Enterprise edition, Firestore
277
+
* does not guarantee a stable ordering. Instead it will pick the most efficient ordering based on
278
+
* the indexes available at the time of query execution. This will result in a different ordering
279
+
* for queries that are otherwise identical. To ensure a stable ordering, always include a unique
280
+
* field in the `order_by` clause, such as `__name__`.
0 commit comments