Blueberry Migration Guide
The future Blueberry release is scheduled for 1/17/2022. It will include a swap of the id field to the _id field for the primary key on data documents.
This migration guide is to prepare customers for the upcoming Blueberry release on 1/17/2022. After the Blueberry release, the id field will no longer be generated on your documents by the data service. Instead, the _id field will be generated, if your document does not already contain an _id.
Until January 17, to support the migration from id to _id, hyper will support both id and _id fields. This means the following:
If you are allowing the hyper data service to generate the id field on newly created documents, hyper will generate both the id and _id fields. These values are guaranteed to be the same when created by the data service.
When retrieving documents within your application, all documents will contain an id and _id field.
- Creating a Document: If you are currently providing an id to the hyper data service, you will need to provide an _id instead. If you are allowing the hyper data service to generate the id field on newly created documents, no change is required when creating new documents, hyper will instead set an _id field on your documents.
- Query Selectors: When retrieving documents within your application or integration, any top-level id selectors will need to change to _id.
- Additionally, any usage of id in your code will instead need to use _id.
We recommend creating your own unique _id key and value in your JSON document within the request body. If the _id key is omitted in your request body, the hyper data service will create a _id key and unique value as the primary key on the document.
Note: A successful response will still include a document identification field named id:
- GET /{appname}/data/{servicename}/{_id}
- DELETE /{appname}/data/{servicename}/{_id}
For the GETand DELETE requests, provide the _id document identifier value in the path parameter instead of an id value.
If the document exists by the _id value, the return response will include the _id property/key instead of the id value:
Note: A successful response will still include a document identification field named id:
This command updates an existing document in your data service, you can change/add any property on the JSON document except the _id property, it must stay the same. If you need to change the _id, simply remove the existing document and create a new document with the new _id.
For the PUT request, provide the _id document identifier value in the path parameter instead of an id value.
For the PUT request body, provide a JSON document with one-to-many fields. Provide _id key and value in your JSON document within the request body instead of an id value.
Note: A successful response will still include a document identification field named id:
The request body takes an array of objects in JSON. You'll need to supply an _id for each document instead of an id.
A successful bulk response body will still include a document identification key/property named id for each document affected by the bulk operation:
- the startkey key match for the document should include the value for the _id property rather than the id property.
- the endkey key match for the document should include the value for the _id property rather than the id property.
- the keys array should contain a collection of key _ids for returning documents rather than the id property.
A successful list response will include a listing of documents. Each document will contain an _id property rather than an id property:
