From 8f120f15e3cad65ee74fe5d1cf5b473fb335b42d Mon Sep 17 00:00:00 2001 From: Mars Lan Date: Wed, 18 Dec 2019 20:39:13 -0800 Subject: [PATCH] Update aspect.md --- docs/what/aspect.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/what/aspect.md b/docs/what/aspect.md index 410b74030a..34a1f6cb70 100644 --- a/docs/what/aspect.md +++ b/docs/what/aspect.md @@ -11,9 +11,9 @@ It is also possible to apply the retention based on time, e.g. only keeps the me While a metadata aspect can be arbitrary complex document with multiple levels of nesting, it is sometimes desirable to break a monolithic aspect into smaller independent aspects. This will provide the benefits of: -1. **Faster read/write**: As metadata aspects are immutable, every `update` will lead to the writing the entire large aspect back to the underlying data store. +1. **Faster read/write**: As metadata aspects are immutable, every "update" will lead to the writing the entire large aspect back to the underlying data store. Likewise, readers will need to retrieve the entire aspect even if it’s only interested in a small part of it. -2. **Ability to independently version different aspects**: For example, one may like to get the change history of all the `ownership metadata` independent of the changes made to `schema metadata` for a dataset. +2. **Ability to independently version different aspects**: For example, one may like to get the change history of all the "ownership metadata" independent of the changes made to "schema metadata" for a dataset. 3. **Help with rest.li endpoint modeling**: While it’s not required to have 1:1 mapping between rest.li endpoints and metadata aspects, it’d follow this pattern naturally, which means one will end up with smaller, more modular, endpoints instead of giant ones. @@ -48,4 +48,4 @@ The [relationship](relationship.md) section explains how this relationship can b } ] } -``` \ No newline at end of file +```