From b32eab42eb45d41e473839134c6af354465c523f Mon Sep 17 00:00:00 2001 From: Uiseop Eom Date: Mon, 26 Feb 2024 05:33:02 +0900 Subject: [PATCH] Fix typo in indexes.mdx (#345) --- www/src/pages/en/modeling/indexes.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/www/src/pages/en/modeling/indexes.mdx b/www/src/pages/en/modeling/indexes.mdx index 1e377571..60e4f7d2 100644 --- a/www/src/pages/en/modeling/indexes.mdx +++ b/www/src/pages/en/modeling/indexes.mdx @@ -56,7 +56,7 @@ indexes: { | -------------- | :----------------------------------: | :------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `index` | `string` | no | Required when the `Index` defined is a _Global/Local Secondary Index_; but is omitted for the table's primary index. | | `collection` | `string`, `string[]` | no | Used when models are joined to a `Service`. When two entities share a `collection` on the same `index`, they can be queried with one request to DynamoDB. The name of the collection should represent what the query would return as a pseudo `Entity`; See the page on [Collections](/en/modeling/collections) for more information on this functionality. | -| `type` | `isolated`, `clustered` | no | Allows you to optimize your index for either [entity isolation](/en/modeling/indexes#isolated-indexes) (high volume of records per partition) or (entity relationships)[#clustered-indexes] (high relationship density per partition). When omitted, ElectroDB defaults to `isolation`. | +| `type` | `isolated`, `clustered` | no | Allows you to optimize your index for either [entity isolation](/en/modeling/indexes#isolated-indexes) (high volume of records per partition) or [entity relationships](/en/modeling/indexes#isolated-indexes) (high relationship density per partition). When omitted, ElectroDB defaults to `isolation`. | | `condition` | `(attr: T) => boolean` | no | A function that accepts all attributes provided every mutation method and returns a boolean value. When provided, ElectroDB will use this function to determine if an index should be be written given a provided set of attributes. This is useful for implementing "sparse" indexes, See the second on [Sparse Indexes](/en/modeling/indexes#sparse-indexes) below for more information on this functionality | | `pk` | `object` | yes | Configuration for the pk of that index or table | | `pk.composite` | `string[]` | yes | An array that represents the order in which attributes are concatenated to composite attributes the key (see [Composite Attributes](#composing-attributes) below for more on this functionality). | @@ -261,7 +261,7 @@ ElectroDB supports many ways to map your indexes to your unique table. From inde ## Index Types -ElectroDB helps manage your key structure, and works to abstract out the details of how your keys are created/formatted. Depending on your unique data set, you may need ElectroDB to optimize your index for either [entity isolation](/en/modeling/indexes#isolated-indexes) (i.e. high volume of records per partition) or (entity relationships)[/en/modeling/indexes#clustered-indexes] (i.e. high relationship density per partition). +ElectroDB helps manage your key structure, and works to abstract out the details of how your keys are created/formatted. Depending on your unique data set, you may need ElectroDB to optimize your index for either [entity isolation](/en/modeling/indexes#isolated-indexes) (i.e. high volume of records per partition) or [entity relationships](/en/modeling/indexes#clustered-indexes) (i.e. high relationship density per partition). This option changes how ElectroDB formats your keys for storage, so it is an important consideration to make early in your modeling phase. As a result, this choice cannot be simply walked back without requiring a migration. The choice between `clustered` and `isolated` depends wholly on your unique dataset and access patterns.