RanchiMall/exchangemarket
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update README.md

Browse Source
This commit is contained in:
tripathyr 2020-07-05 22:16:52 +05:30 committed by GitHub
parent 9be2c5103d
commit be52706a05
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 24 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
README.md
View File

@ -467,13 +467,15 @@ Parameters while sending
#### Options
* `receiverID` - receiver of the data
* `application` - application using the data
* `comment` - user comment of the data
* `application` - name of the application sending the general data
* `comment` - user comment for the data
Important: Never use senderIDs in SEND GENERAL DATA options. The system automatically picks the FLO ID of the sender from FLO Globals. Its a common mistake developers make.
Type is mandatory in SEND GENERAL DATA because without at least one data identifier like TYPE, the message cannot be retrieved back
Application field is used by the Cloud to judge whether this message should be deleted after 7 days, or stored permanently. Developers should be careful not to change value of application field if the default value enables the message to be stored permanently. Currently messages sent from subadmins for applications notified by the cloud in the FLO Blockchain are stored permanently. So do not change application field as a caution. Use the comment field.
### REQUEST GENERAL DATA
Parameters while requesting
@ -483,8 +485,8 @@ Parameters while requesting
#### request options
* `receiverID` - receiver FLO ID of the data. ReceiverID is always a single value in our cloud design
* `senderIDs` - array of senderIDs. This must be in an array even if a single senderID is requested
* `application` - application of the data
* `comment` - comment of the data
* `application` - name of the application that sent the general data
* `comment` - comments for the data
* `lowerVectorClock` - VC from which the data is to be requested
* `upperVectorClock` - VC till which the data is to be requested
* `atVectorClock` - VC at which the data is to requested
@ -496,7 +498,9 @@ floDapps.getNextGeneralData should be used to retrieve the output in the client
Type is mandatory in REQUEST GENERAL DATA. So every TYPE of general data must be requested individually and separately.
If you want to use requests to give results from all types at one go, use Application Data.
If you want to use requests to give results from all types at one go, use Application Data.
Application field is used by the Cloud to judge whether this message should be deleted after 7 days, or stored permanently. Developers should be careful not to change value of application field if the default value enables the message to be stored permanently. Currently messages sent from subadmins for applications notified by the cloud in the FLO Blockchain are stored permanently. So do not change application field as a caution. Use the comment field.
## 5. OBJECT DATA PARAMETERS AND OPTIONS
@ -508,8 +512,8 @@ Note: The object data corresponding with Object Name must be defined in floGloba
#### Options
* `receiverID` - receiver FLO ID of the data. If this is not specified, the admin ID will be taken as receiverID
* `application` - application using the data
* `comment` - comment of the data
* `application` - name of the application for sending the object data
* `comment` - comment for the object data
Note: Never use senderIDs in RESET and UPDATE. The system automatically picks the FLO ID of the sender from FLO Globals. Its a common mistake developers make.
@ -523,15 +527,18 @@ Note: Type field is never used in RESET, UPDATE or REQUEST operations in Object
#### request options
* `receiverID` - receiver FLO ID of the data. ReceiverID is always a single value in our cloud design. If this is not specified, the admin ID will be taken as receiverID
* `senderIDs` - array of senderIDs. This must be in an array even if a single senderID is requested
* `application` - application of the data
* `comment` - comment of the data
* `application` - name of the application for which the object data is intended
* `comment` - comment for the object data
* `lowerVectorClock` - VC from which the data is to be requested
* `upperVectorClock` - VC till which the data is to be requested
* `atVectorClock` - VC at which the data is to requested
* `mostRecent` - boolean (true: request only the recent data matching the pattern. Just the last one.)
Note: The output is available in floGlobals.appObjects[objectName] after request Object Data promise is resolved
Note: Type field is never used while RESET, UPDATE or REQUEST operations in Object Data. Type field is internally blocked for Object Data.
The output is available in floGlobals.appObjects[objectName] after request Object Data promise is resolved
Type field is never used while RESET, UPDATE or REQUEST operations in Object Data. Type field is internally blocked for Object Data.
Application field is used by the Cloud to judge whether this message should be deleted after 7 days, or stored permanently. Developers should be careful not to change value of application field if the default value enables the message to be stored permanently. Currently messages sent from subadmins for applications notified by the cloud in the FLO Blockchain are stored permanently. So do not change application field as a caution. Use the comment field.
## 6. APPLICATION DATA PARAMETERS, OPTIONS AND EXPLANATIONS
@ -543,13 +550,15 @@ Parameters while sending
#### Options
* `receiverID` - receiver of the data. If this is not specified, the admin ID will be taken as receiverID
* `application` - application using the data
* `comment` - user comment of the data
* `application` - name of the application sending the data
* `comment` - user comment for the data
Important: Never use senderIDs in SEND DATA options. The system automatically picks the FLO ID of the sender from FLO Globals. Its a common mistake developers make.
Type is mandatory in SEND APPLICATION DATA because without at least one data identifier like TYPE, the message cannot be retrieved back
Application field is used by the Cloud to judge whether this message should be deleted after 7 days, or stored permanently. Developers should be careful not to change value of application field if the default value enables the message to be stored permanently. Currently messages sent from subadmins for applications notified by the cloud in the FLO Blockchain are stored permanently. So do not change application field as a caution. Use the comment field.
### REQUEST APPLICATION DATA
#### Mandatory Parameters while requesting
@ -576,6 +585,8 @@ Note: Application Data results are not stored in local IndexedDB by Standard Op
Note: If a blank REQUEST APPLICATION DATA is made, then cloud will give all application data at the admin ID of the application
Note: Application field is used by the Cloud to judge whether this message should be deleted after 7 days, or stored permanently. Developers should be careful not to change value of application field if the default value enables the message to be stored permanently. Currently messages sent from subadmins for applications notified by the cloud in the FLO Blockchain are stored permanently. So do not change application field as a caution. Use the comment field.
# Examples for FLO Cloud data operations