3
Requirements AzureData
Colby Williams редактировал(а) эту страницу 2018-03-16 15:08:54 -04:00
Phase 0: Refactor
- Cosmos DB DocumentDB/SQL API Coverage
- Migrate code that can be reused by other SDKs to AzureCore
- Support full Cosmos DB DocumentDB/SQL API
- TokenProvider updates to support multiple Auth/Resource Token requirements
- Add metadata to response object
- Implement optimistic concurrency control (OCC) by adding appropriate Headers
If-None-Match
on all GETIf-Modified-Since
on GET (ignored whenIf-None-Match
is specified)If-Match
on PUT and DELETE
- Conflict resolution
- Latest wins (silent)
- Mine wins (silent)
- Manual (callback)
- Save tokens to Keychain (AzureCore)
- Querying resources
- Support for "raw" SQL queries (validation?)
Query
type and custom syntax language for chaining together conditions
- Overrides for partition keys
- Add
altLink
property to Resource and populate fromx-ms-alt-content-path
- Note:
altLink
will only be populated ifselfLink
is populated as both require the resource to be committed to the remote database to get those values
- Note:
- Create and persist a record of
id
<->_rid
relationships with an API for getting one with the other - Add
createOrReplace
API for Documents using thex-ms-documentdb-is-upsert
header
Phase 1: Data Persistence
- Offline persistence is enabled by default (for all resources)
- User has option to disable offline persistence (for all resources)
- Data is successfully written remotely before caching locally
- Only READING is supported while device is offline, WRITE throws a (useful) error
- Add
fromCache
to response object when returning data from cache (device offline) - Simple API to Purge entire data cache
DELETE
ing a resource remotely deletes the cached version (only if the delete was successful indicated by a response status code of204 No Content
)- If
GET
request returns404 Not Found
(deleted remotely), check for existing cashed/local resource and delete - When deleting the cached resource, also delete the persisted record the resources'
id
<->_rid
relationship - Encryption interface for user to implement custom
encrypt
anddecrypt
- Resources are cached on disk as folders/files (opposed to SQLite, etc.) matching the path constructed using resources' (_rid) hierarchy (currently stored in the
selfLink
property)
Example
A Document in the database account https://databaseaccount.database.com
located at the following path (selfLink
):
dbs/1KtjAA==/colls/1KtjAImkcgw=/docs/1KtjAImkcgwBAAAAAAAAAA==/
Would be represented in the file system like this:
[databaseaccount.database.com]
└──[dbs]
└──[1KtjAA==]
├──1KtjAA==.json
└──[colls]
└──[1KtjAImkcgw=]
├──1KtjAImkcgw=.json
└──[docs]
└──[1KtjAImkcgwBAAAAAAAAAA==]
├──1KtjAImkcgwBAAAAAAAAAA==.json
└──[attachments]
└──...
Phase 2: Offline Write
- Add WRITE support when offline
- Queue writes when offline
- Automatically push any local changes as soon as device comes back online
- Send global notification to let user know data changed
Phase 3: Granular Persistence Control
- User has option to disable offline persistence for collections only (documents would respect parent collection option persistence)
- Attachment
Phase 4: Time-To-Live
- Add Time-To-Live (TTL) functionality to improve GET performance for non-volatile data
Phase N: Change Feed
- Change feed support
- Multiple Database Account support