Hi.
I’m wondering something important for my use case :
Does (and in a right case how) Sync Gateway manage views replication of a local database or
are views re-generated locally after a pull ?
No, views are local. Replication only copies documents.
So, if i get if correctly, replication will force local views generation from scratch on a new local DB…
I think this process can be expensive on mobile architecture right ?
What is the amount of views I should not go over on a mobile platform ?
What I have understood is the best way to look at it is, to create one view per document type and use setDocumentType property of that view. Hence the mapper will be called only when that type of document is synced to fill the view/index.
Secondly try to avoid writing views which will emit keys based on 2 different document types. Instead create 2 views.
Also when emitting a key if you need to access other document then try to denormalise data or duplicate some data. Because you never know which document is going to be synced first if not simulating priority by using filtered replication.
Keys are more like combination of columns used in where clause and order by of SQL. and values are your select. Do think like you cant have joins and based on that design your document structure.
Does this mean that views should not be defined on the server, only created locally on CBLite?
Having used Cloudant previously, I have been replicating my views as well as other documents from the server into the local db.
Replicating views is problematic:
- The map functions are implemented in JavaScript, which has much lower performance than native code.
- It’s not easy to synchronize changes in the views with changes in the app code that uses the views, since they live on different servers. If the view logic gets out of sync with the app’s logic, it can totally break the app.
- Apple’s app-store terms explicitly forbid iOS apps from downloading and running code.