Expiring Assets #
The CosyncAsset object is created by the client after the upload process associated with CosyncAssetUpload object is completed. The Cosync Sample Code will in fact create the CosyncAsset object automatically, once the status property of the CosyncAssetUpload is set to uploaded. The CosyncAsset object is simply there to provide a ledger record in MongoDB Real of the uploaded asset - the actual asset itself resides with the Amazon S3 Storage system. The client application code needs a CosyncAsset object to be able to retrieve the URLs associated with an asset.
Best practice #
A CosyncAsset object does not need to be placed within the same Realm partition as the CosyncAssetUpload. In fact, the best practice is to always place the CosyncAssetUpload object within a private user partition. The CosyncAssetUpload object has a property called assetPartition that specifies the partition in which the CosyncAsset object will be created.
Remember, it is the CosyncAsset object that enables client side application code to find the asset that is stored in Amazon S3. This object is created by the Cosync backend server-side code attached to the MongoDB Realm Application once the client has signaled an upload complete by setting the status property of the CosyncAssetUpload object to uploaded.
As far as Cosync is concerned, assets are immutable objects, i.e., once uploaded they do not change. Any change to an asset requires a second upload, and a second asset. The CosyncAsset object will record a number of readUrl(s) that permit an application to access the asset on Amazon S3. A non-expiring asset will have an expirationHours property set to zero. Expiring assets will have a property called expiration, which records the date in UTC when the asset’s readUrl(s) expire.
Refreshing Expired Assets #
The function CosyncRefreshAsset() is used to update the readUrl(s) on an asset that has expired. The client application should call this function and pass the asset Id of the expired asset to bring it up to date.