Change Existing Index Specs on a Soup

To change existing index specs, call the applicable soup alteration method.

Keep these important performance tips in mind when reindexing data:

The reIndexData argument is optional, because reindexing can be expensive. When reIndexData is set to false, expect your throughput to be faster by an order of magnitude.
Altering a soup that already contains data can degrade your app’s performance. Setting reIndexData to true worsens the performance hit.
As a performance guideline, expect the alterSoup() operation to take one second per 1000 records when reIndexData is set to true. Individual performance varies according to device capabilities, the size of the elements, and the number of indexes.
alterSoup() and reindexSoup() perform better for conversion to, or creation of, JSON1 index specs than for other index spec types.
Insert performance tends to be faster with JSON1 index specs.
Database size is smaller with JSON1 index specs.
Query performance is typically unaffected by JSON1 index specs.
Other SmartStore operations must wait for the soup alteration to complete.
If the operation is interrupted—for example, if the user exits the application—the operation automatically resumes when the application reopens the SmartStore database.

If you’ve registered a soup to use the external storage feature, use the alterSoup methods described in Alter a Soup with External Storage.

In hybrid apps, call:

In addition to success and error callbacks, this function takes the following arguments:

Parameters

Parameter Name	Argument Description
`soupName`	String. Pass in the name of the soup.
`indexSpecs`	Array. Pass in the set of index entries in the index specification.
`reIndexData`	Boolean. Indicate whether you want the function to re-index the soup after replacing the index specifications.

The success callback supports a single parameter that contains the soup name. For example:

The following example demonstrates a simple soup alteration. To start, the developer defines a soup that’s indexed on name and address fields, and then upserts an agent record.

When time and experience show that users really wanted to query their agents by "agentNumber" rather than address, the developer decides to drop the index on address and add an index on agentNumber.

If the developer sets the reIndexData parameter to false, a query on agentNumber does not find the already inserted entry (”James Bond”). However, you can query that record by name. To support queries by agentNumber, you’d first have to call navigator.smartstore.reIndexSoup("myAgents", ["agentNumber"])

In an Android native app, call:

Objective-C:

In Swift, use the Objective-C method.