In fact, existing objects will not be indexed automatically. You must load and save all your old objects (without an index) in order to create the necessary indexes for these objects.
Note, however, that changing a property from unindexed to indexed does not affect existing entities that could have been created before the change. Filtering queries by property will not return such existing objects, because objects were not written to the query index when they were created. To make entities available for future queries, you must rewrite them in the data warehouse so that they are entered into the corresponding indexes. That is, you must do for each such existing object:
Get (get) the object from the data store. Write (put) the object back to the data warehouse. Similarly, changing a property from indexed to unindexed affects only entities subsequently written to the data warehouse. Index entries for any existing objects with this property will continue to exist until the entities are updated or deleted. To avoid unwanted results, you should clear your code of all requests that filter or sort by property (now unindexed). ( source )
Note that the documentation does not explicitly state the same for compiled indexes. When you deploy a new composite index, the index appears in the developer console as a “building” until it reaches a “maintenance” state. I’m not sure what it was he who built there, as a rule, I re-saved all my essences, and everything worked as it should.
Automatically generated is a keyword that tells you whether you manually created this index or whether it was created by the dev server when you made a request that required this index. It has nothing to do with how and when indexes are created for entities.
The <datastore-indexes> element has an autoGenerate attribute that controls whether this file should be viewed together with an automatically generated index configuration. See Using the Automatic Index Configuration section below. ( source )
When you created a new index and want this index for all existing entities, I recommend that you create a cursor query to handle this. Usually I look at this request in the admin backend and run the request until the results are received. Why exhibit things? If you have many entities, this task can work longer than the allowed 60 seconds in the interface or 10 minutes in the backend. By exposing this, I can use front end instance time and no need to worry about time constraints.