> > The only drawback would be that if you allow these fields to be renamed, > it would require updating every document containing that field. >
Is there a built-in function for renaming keys? That would be very handy. If a user renames a key on device A, and then changes the value for the old key on device B, what would happen? You would essentially want the new key from device A along with the new value from device B. But I don't see how that could be automated unless I had a mapping from the old key to the new key. Either that or it would result in a conflict I presume. On Friday, June 5, 2015 at 9:53:43 AM UTC-6, Jens Alfke wrote: > > Interesting — so you have sort of a build-your-own-database app, where > users can define their own fields and then populate records with them? > > The JSON you showed looks reasonable, although it’ll help performance if > you can avoid using UUIDs for the field identifiers. The shorter the > better. Have you considered making the field identifier be the user-visible > name of the field, perhaps with a prefix added to disambiguate it from the > built-in fields like “sortOrder”? The only drawback would be that if you > allow these fields to be renamed, it would require updating every document > containing that field. > > I also need to be able to query by any of the fields in the database in a > variety of ways. For example, date ranges, numeric ranges, full text > queries, empty values, not empty values, possibly all combined. > > > Couchbase Lite isn’t super good at this. It’s easy to do in SQL because > you can piece together a SELECT statement at runtime and the database will > evaluate it, and even if the data isn’t indexed for that query it’ll do its > best by linear searching. It also knows how to combine results from > multiple indexes. Couchbase Lite’s map/reduce system requires that you have > an index for what you want to search on, and if you need to merge results > from multiple indexes you have to do it by hand. We’d like to improve this > in the future (possibly by adopting the N1QL query language) but that > doesn’t help you now. > > Take a look at the new CBLQueryBuilder > <https://github.com/couchbase/couchbase-lite-ios/wiki/Query-Builder> class > available in 1.1 for iOS/Mac. It’s similar to Core Data’s NSFetchRequest: > it lets you define a query using NSPredicate, NSExpression and > NSSortDescriptor. Behind the scenes it will create a view to generate the > necessary index. If you’re using this for ad-hoc queries, it may end up > creating a lot of views, which can reduce performance, so you may want to > manually delete them from time to time. > > —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/450c619b-aaeb-44ee-b21a-7a16265d58c5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
