Fix typo in indexes.mdx (#345)

tywalch · Feb 25, 2024 · b32eab4 · b32eab4
1 parent 58ffe11
commit b32eab4
Showing 1 changed file with 2 additions and 2 deletions.
diff --git 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.