When manually creating a SQL view for an app's backend, as is sometimes done for performance reasons, it is important not to create random identifiers for the view rows in the view definition. For example, sometimes when such a view is created, the first field would be defined as:
...
If a developer has written SQL views for Helium apps without knowing about this problem, it is strongly recommended that he or she inspect the project's SQL to make sure it doesn't contain uuid_generate_v4() or similar functions. Because the way this issue manifests as a bug is subtle, a particular app might falsely appear to be functioning correctly, and relying on bug reports will likely be insufficient to spot this.
...
Implement one of the following alternatives for the view in question:
- if If you have a UUID from one of the view's constituent objects that are going to be unique to each record in the view, you can set the ID to that.
- similarlySimilarly, if you have a unique non-UUID field, you could potentially use that to .sortAsc or .sortDesc your collection before loopingprocessing.
Use materialized views (if you have no option but to use uuid_generate_v4()).