give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "*SEE FAB-3067 FOR LATEST DESIGN.*         *Background/Motivation*    CouchDB rich queries require indexes to perform well.  Additionally, queries with a sort require an index.  Fabric supports CouchDB declarative JSON queries in chaincode as defined at [http://docs.couchdb.org/en/2.0.0/api/database/find.html]. This work item proposes to add support for indexes as defined at the same CouchDB doc page, as well as management lifecycle to create and drop indexes for peers on a channel.    *Index Management*    CouchDB queries are defined in chaincode and executed from chaincode, therefore the index management lifecycle should mirror the chaincode management lifecycle.  Upon implementation of FAB-6042, chaincode definition will be provided in a resource configuration tree in a config transaction, and upon processing the config transaction all peers will ‘deploy’ the chaincode on the channel.   Similarly, index definition will be provided in the same resource configuration tree under the chaincode definition, and upon processing the config transaction all peers will ‘deploy’ the index to their couchdb state database (if their state database is in fact configured to be couchdb).    The index definition may be in the same config transaction as the chaincode definition, or in a later config transaction. This is useful since new indexes for a chaincode may be identified after chaincode install/instantiate time, especially if the chaincode allowed arbitrary queries to be passed through. The index definition under the chaincode may also be removed with a config transaction, in which case all peers would drop the index. The index change against state database must succeed for the block with the config transaction to be considered committed, just like regular state database changes must succeed for blocks with normal transactions to be considered committed.    The index definition will be included in the resource configuration tree in a new StateDatabaseImpl group under the chaincode resource definition, which can include state database specific metadata.  For example if a peer’s state database is CouchDB, there will be a resource configuration transaction processor listener that will look for a CouchDB group under the chaincode’s StateDatabaseImpl group, and process any new index creations or drops:  {noformat}  <Resources>      <Chaincodes>          <Chaincode1>              (ID) : {                  CodeHash                  InstalledVersion              }              (EndorsementPolicy) : {                  PolicyReference              }              <StateDatabaseImpl>                   <CouchDB>                        <Indexes>                             (IndexName):{                                   IndexDefinition                             }          ...  {noformat}  If the peer's state database is LevelDB, the CouchDB group is ignored. In this way, database specific artifacts supporting a chaincode can be managed. (Note - If relational database support is added in the future, the DDL for the relational schema supporting the chaincode could be managed using the same mechanism.)    *Implementation Details*    Currently there is one CouchDB database per channel, matching the commit granularity for blocks (channel level).  However, logically chaincode key/value data is scoped per chaincode within the channel.  That is, key/value data can only be accessed or queried by the chaincode that created the data. Similarly, indexes should only apply to data from the corresponding chaincode  (it would not make sense to apply an index from cc1 to documents from cc2).  Since CouchDB indexes apply to all documents within a CouchDB database, the granularity of CouchDB databases will have to change from one db per channel, to one db per channel/chaincode.  This also aligns with chaincode lifecycle which is defined at the channel/chaincode level in the resource configuration tree.  That is, different channels may have different versions of a chaincode ‘deployed’ at any point in time, with corresponding indexes specific to that chaincode version also 'deployed' to the state database.    Implementation implications:   - CouchDB database name will be based on <channel_chaincode>. See subtask FAB-7130 for more details.   - VersionedDB for the CouchDB state database impl will logically remain at channel level (since commits are applied at channel level), however there will be N channel_chaincode databases, rather than a single database defined for the VersionedDB.   - Data will be committed to each chaincode-specific database upon block commit.  Failure to commit to any chaincode-specific database will result in block commit failure, and will be fully recoverable using existing state database recovery logic (idempotent retries).   - Performance has been evaluated and there is no material difference between bulk writing to one CouchDB database or bulk writing to N CouchDB databases in parallel during block commit processing (actually, parallel bulk updates is the most performant method of writing to CouchDB).   - State database recovery logic will continue to utilize a channel scoped savepoint document that is written upon commit of all chaincode data in the block. Since the CouchDB database will no longer be channel scoped, the savepoint document per channel will be saved to a new CouchDB database to store state database metadata.   - For environments upgrading from 1.0 with existing channel-scoped databases, upon peer 1.1 start the channel_chaincode scoped databases will not be found and will be created and populated from the chain data following existing recovery process. In release notes we can recommend that CouchDB data be dropped when upgrading from 1.0 to 1.1, but even if this is not done there is no functional problem, there will simply be a set of orphaned data in the database (orphaned 1.0 channel-scoped databases, as well as newly created 1.1 channel/chaincode-scoped databases). The orphaned 1.0 channel-scoped databases can be dropped anytime, it's just easier to drop all the CouchDB data prior to the 1.1 upgrade.    *Future Work*    In the future, there may also be a need to create/drop an index for a specific peer. For example suppose an auditor organization performs additional queries against their peers, which are never executed on other peers. Additional indexes may be required on these auditor peers only. As such a peer API to manage indexes on that peer only may be needed in the future. This is not in the scope of this work item. However this work item is designed in such a way that it could be added in the future (for example additional indexes may exist in state database over and above the indexes that are defined in the resource configuration tree).                         "
Answer: 115184.0