Couchbase support N1QL since 4.0,It is a great enhancement for Couchbase Server,
but If I use Couchbase Mobile, I can only using Map/Reduce to query Data, So I am limited on query design(for example Map/Reduce can not query data cross document, but in N1QL we can use join) ,on CRUD operations(N1QL is so easy to do this) etc.
but N1QL is design for Couchbase Server,It can not migrate to CBL directly.Is it possible to implement N1QL on CBL, or any plan?
No plan. We want to integrate with existing platform query mechanisms, for example Core Data and NSPredicate on iOS/Mac, which we already support. We’ve talked about integrating with LINQ on .NET.
Map/Reduce can not query data cross document, but in N1QL we can use join
There are ways to do this using map/reduce, with grouping or reduce. But I agree it’s more limited.
Thanks,
How about Android?
We want to integrate with query APIs on all our platforms. I didn’t mention Java/Android because I’m personally not aware of a standard query API there. But I know it’s being investigated. @hideki or @zgramana may be able to say more.
We’re currently planning to implement the Java Stream API, and using a backport to support Android.
Do you have any plan to implement on REST API level?
To be blunt thatstha huge huge disappointment to me.
We use couch because it runs everywhere with a common api, exposed to diffetentdlanguage bindings.
What are you thinking enterprise customers want ?
Its write once , run everywhere .
It feels like there maybe some missunderstanding but when we write a server app in golang that uses forest / bleveBwe expect that exact same api to be available on mobile. You have the engine there and the api there on mobile. Just expose it. If you want to expose an api to matches native dbs in ios / android do that as your planning to also.
This really seems backwards. Can you explain the use cases that led you to this ?
We use couch because it runs everywhere with a common api, exposed to diffetentdlanguage bindings.
Couchbase Lite is not the same as Couchbase Server. They run on drastically different hardware, for different use cases, and have almost no code in common. In addition, Couchbase Lite supports multi-master replication, which Couchbase Server doesn’t, hence the need for the Sync Gateway to handle the needed protocols and metadata.
It feels like there maybe some missunderstanding but when we write a server app in golang that uses forest / bleveBwe expect that exact same api to be available on mobile
Yes, that’s definitely a misunderstanding. If we’ve given that impression somewhere, please point it out and we’ll fix it.
I can’t think of any cases where a high-end server database also exists on mobile. There’s no mobile version of Oracle, Cassandra, or MongoDB. It’s the same reason that Ferrari and Lamborghini don’t make compact cars — if they did they’d be terrible for that purpose.
You have the engine there and the api there on mobile. Just expose it.
No, we don’t. As I said, there is no common code other than ForestDB itself (which is a low-level key-value store.) Couchbase Lite is implemented in Objective-C (for iOS), Java (for Android) and C# (for the Xamarin runtime.)
This really seems backwards. Can you explain the use cases that led you to this ?
First off, one can’t just take server software and stuff it into a mobile device. We started in 2011 trying to do this — porting CouchDB to iOS/Android — and found that it was much too heavyweight & slow to work there, so we started over with native code optimized for mobile devices.
With regard to N1QL: It’s implemented in Go. The Go language has a very unusual runtime — basic things like calling conventions, stack layout and memory management are totally nonstandard. This makes it very difficult to use Go code in a non-Go program. Until very recently there was no support for using Go at all on mobile devices; there is some now, but it’s still pretty experimental, and it focuses on all-Go apps. Moreover, it incurs a lot of overhead because Go has to use its own separate heap, and the Go libraries have to be bundled into the app. If you add to that the code size of N1QL, this would be a ton of overhead for mobile apps, which generally try to keep their size low.
The commonality between Couchbase and Couchbase Lite is the document data model, the map/reduce query system, and (using Sync Gateway) multi-master replication. We will be adding more commonality in the future (on both sides) but it’s a pretty big architectural effort.
Hey Jens
Thanks for the in depth explanation.
Yes it is a misunderstanding and my fault.
I program golang and run bleve on everything including mobile. It’s very easy as you know when you base it on boltdb.
I guess iIassuming that because forestdd is golang, that you guys would be supporting it on mobile also. I also assuming you would wrap the api with grpc / protocol buffers rather than using FFI. ItsIttrue FFI is a bit difficultondigolang mobile.
Anyway my own expectations dashed.
ForestDB is written in C, not Go. We have no Go code in Couchbase Lite.