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 #### Options
* `receiverID` - receiver of the data * `receiverID` - receiver of the data
* `application` - application using the data * `application` - name of the application sending the general data
* `comment` - user comment of the 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. 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 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 ### REQUEST GENERAL DATA
Parameters while requesting Parameters while requesting
@ -483,8 +485,8 @@ Parameters while requesting
#### request options #### request options
* `receiverID` - receiver FLO ID of the data. ReceiverID is always a single value in our cloud design * `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 * `senderIDs` - array of senderIDs. This must be in an array even if a single senderID is requested
* `application` - application of the data * `application` - name of the application that sent the general data
* `comment` - comment of the data * `comment` - comments for the data
* `lowerVectorClock` - VC from which the data is to be requested * `lowerVectorClock` - VC from which the data is to be requested
* `upperVectorClock` - VC till 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 * `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. 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 ## 5. OBJECT DATA PARAMETERS AND OPTIONS
@ -508,8 +512,8 @@ Note: The object data corresponding with Object Name must be defined in floGloba
#### Options #### Options
* `receiverID` - receiver FLO ID of the data. If this is not specified, the admin ID will be taken as receiverID * `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 * `application` - name of the application for sending the object data
* `comment` - comment of the 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. 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 #### 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 * `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 * `senderIDs` - array of senderIDs. This must be in an array even if a single senderID is requested
* `application` - application of the data * `application` - name of the application for which the object data is intended
* `comment` - comment of the data * `comment` - comment for the object data
* `lowerVectorClock` - VC from which the data is to be requested * `lowerVectorClock` - VC from which the data is to be requested
* `upperVectorClock` - VC till 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 * `atVectorClock` - VC at which the data is to requested
* `mostRecent` - boolean (true: request only the recent data matching the pattern. Just the last one.) * `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 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.
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 ## 6. APPLICATION DATA PARAMETERS, OPTIONS AND EXPLANATIONS
@ -543,13 +550,15 @@ Parameters while sending
#### Options #### Options
* `receiverID` - receiver of the data. If this is not specified, the admin ID will be taken as receiverID * `receiverID` - receiver of the data. If this is not specified, the admin ID will be taken as receiverID
* `application` - application using the data * `application` - name of the application sending the data
* `comment` - user comment of 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. 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 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 ### REQUEST APPLICATION DATA
#### Mandatory Parameters while requesting #### 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: 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 # Examples for FLO Cloud data operations