On Thursday, 28 August 2014 17:37:28 UTC+1, Jens Alfke wrote: > > > On Aug 27, 2014, at 9:13 AM, Toby UP <[email protected] <javascript:>> > wrote: > > In iOS I am querying 'object' documents using 2 different views and then > setting them up as live queries that run in the background. The first view > map function queries all documents where the 'owned_by' property contains > the current users email and the second uses the boundingbox function to get > all documents within close proximity to the user via their 'latitude' and > 'longitude' properties. The properties are constantly changing and thus the > live query will potentially be returning new 'object' documents several > times a minute. > > > I'm sort of confused by that last statement. If the live query is > returning new results, that implies the database changed. But from your use > case it sounds like it's the *user's location* that changes. That > wouldn't cause the live query to update; instead you'd presumably be > running a new query with different lat/lon coords. >
First thank you so much for getting back to me about this. Your help in understanding is very much appreciated. Yes, your presumption above is correct. Each time the users location changes a new query is generated based on the users new latitude / longitude coordinates. The reason it is set up as a liveQuery each time is that other properties relating to these document objects can be changed by other users and so these changes will then trigger the local document to be updated on the device as they happen. > It is my understanding that I can't create a dynamic condition for a view > (i.e. the 'source_ref' properties of the 'object' documents as they are > returned by a live query) so is there a simple way I am missing that this > can be achieved using views map reduce function or can I simply create an > array of the document ID's I want to pull from the server to my local db > and query them one by one in the background? > > > I think there are two different issues here (or maybe I'm just confused.) > > First there's the issue of joins. You can't directly join from the object > docs to the source docs. You'll need to collect the set of source_ref > values and then get those documents. If they're local, just call [database > documentWithID:] for each one. (CBLDatabase has a document cache and will > never instantiate multiple CBLDocument objects for the same ID.) > The majority of the 'source' documents won't exist locally. However if they don't and I make a call to the local database via [database documentWithID:] will it create a blank document and then subsequently pull an existing document with that ID from the server seeing as it is now created locally. Each 'source' document has a custom predefined '_id' property as it relates to third party data it's referencing so I can guarantee there should only be one 'source' document with the _id I specify. Also just to clarify there is no way to do what Alexander suggested in the reply above (have you tried joining with views? http://docs.couchdb.org/en/latest/couchapp/views/joins.html <http://www.google.com/url?q=http%3A%2F%2Fdocs.couchdb.org%2Fen%2Flatest%2Fcouchapp%2Fviews%2Fjoins.html&sa=D&sntz=1&usg=AFQjCNHWkOv7imToLBUgErJCvhxB9jLhMw>) and create a view that includes the 'source' document (in full) as an adjacent row for each 'object' document row using it's 'source_ref' property every time the live query returns results? > Second, it sounds like you want to pull the source documents lazily from > the server instead of replicating the entire data set to the device. You'll > need to do that by setting the documentIDs property of the replication. Two > things to keep in mind: > > 1. The replicator only checks this property when the replication > starts. That means that, if you change the property on a running > CBLReplication, you'll need to stop and re-start it. > 2. If you want to keep getting updates of all the source documents > you've downloaded, you'll need to persistently store the entire set of > source document IDs somewhere so you can set the replication's documentIDs > on re-launch of the app. > > (I know this isn't ideal, especially condition 2. Our architecture isn't > yet optimized for keeping a subset of the server database; that's a high > priority feature for version 2.0.) > As there will potentially be an exponential amount of documents created on the server database that will never need to be seen/accessed locally by individual devices (as they are purely based on the users geo-location) I feel the only way to safeguard future performance from unnecessary replications and an enormous local database on every device, is to only pull a subset of the relevant data from the server rather than replicating all data to the local device. I originally thought perhaps 'channels' would be the answer but the parameters for what documents need to be replicated by a device are so variable and ever changing (being geo based) that I can't see how channels could be used for this. So I have two questions regarding the above: 1. For my understanding, when creating a view within iOS where does it get actioned exactly - on the device or on the server? For example if not using channels does sync_gateway attempt to push replications of all documents to the device and then the device has to constantly update it's locally iOS specified views to do any filtering? If there is a lot of data on the server will each device suffer performance wise with this approach seeing as it only ever needs a small subset of data? 2. Is the solution to do as you suggest above specify documentID properties for replications. What is involved exactly in this if the documents that need accessing are constantly changing as the users location updates etc. will I be continually destroying and recreating replications for this to work? Many thanks again for your help. > > Hope this helps. If I've misunderstood your issues, please clarify! > > —Jens > -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/b5073a03-8aba-4435-ab14-9c213c70be65%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
