Hi Jens, Thanks for the tips. > >> Sure. I'm using the array of keys for a table view. (In the actual app, >> there are a few more fields I export). I use a related CQLLiveQuery in a >> nstableviewdatasource. I just pull in the keys for the items in the >> tableviewcell instead of having to load the model for every row. > > It sounds like you want to display a list of the comments on a post, then? In > that case you don't want the text of the post to be the key, since the key is > what the view is sorted by. It doesn't sound useful to get a list of all the > comments in the entire database in alphabetical order :) Instead you probably > want the view to have a primary sort by post ID (so you can use a range to > get the comments on a single post) and a secondary sort by date (so you can > show them in chronological order). > > This section from JChris's old CouchDB book talks about how to do pretty much > exactly that. Thanks. I actually realized I needed them by type, then date. I think I did it this way based on a comment in ... actually I don't remember. The examples for emit always show emitting the whole doc, I never thought to consider you could emit an array - that's where text and user would go if I had the user data.
> As for getting the user name -- there are two choices: > * Put the user name (along with the ID) in the comment document. Then > it can be emitted into the view. The downside is that if users can change > their names, you have to go through every comment and update the name. > * Emit only the user ID in the view value, then look up the user name > while displaying, i.e. get the document with that ID and get its "name" > property. This shouldn't cause much DB activity, if there aren't a huge > number of users, because CBL caches recently-accessed documents in memory. > (Really, it's exactly what a relational database would be doing when you use > a JOIN in the query.) If it does turn out to be an issue, you can construct a > view that maps user ID to user name, and keep a live query of it; that will > end up caching the mapping and keeping it up to date. I don't think storing username in the comment item is probably the way to go since the user could change their name - I don't want to have to write a rewrite username bot. I like the index idea - I'll consider that. Since the question though, I've realized I may need more data from the both the comment and user objects so it may make sense to just pull up the objects. I'll have to measure to see if it kills performance. Thanks for your feedback. -- 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/EC8E9363-0836-4C63-BA26-C97E7DEA646C%40gmail.com. For more options, visit https://groups.google.com/d/optout.
