CouchDB for iOS vs Core Data

[zardon]

Hello there.

I am very new to CouchDB, let alone CouchDB for iOS.

I have played a bit with Mongo but not too much, and CouchDB for iOS
interests me, but I'm finding it a bit hard to understand the context
of where CouchDB for iOS sits

I am wondering what the benefits of using CouchDB are over using
Apple's own Core Data, is it faster, is it better at doing queries, is
it easier to code queries, or is better for native data storage?

I'm wondering if it would also be possible for the guys who do CouchDB
for iOS to demonstrate it in a video form, like a screencast; or at
the very least offer a quick overview of where it sits with iOS
development, and why/when to use it.

I apologize if these questions have been answered elsewhere.

Thank you for your time.

[Andrew W. Donoho]

On May 12, 2011, at 15:15 , zardon wrote:

> I am wondering what the benefits of using CouchDB are over using
> Apple's own Core Data, is it faster, is it better at doing queries, is
> it easier to code queries, or is better for native data storage?

Zardon,

The virtues of CouchDB are extolled elsewhere. I'm restricting myself to CouchDB v Core Data.

Core Data is an Object Graph with a persistence mechanism. It is an attempt to make model data storage as natural a process for Objective-C programmers as possible. At this, it largely succeeds.

What is the big difference between CD and CouchDB? Schema flexibility. CD requires a compile-time schema definition. CouchDB, as a document store, allows the schema to evolve without having to revise the application. The second difference is CouchDB can naturally replicate its data to another CouchDB instance. CD does not have any concept of data replication.

Anon,
Andrew
____________________________________
Andrew W. Donoho
Donoho Design Group, L.L.C.
a...@DDG.com, +1 (512) 750-7596, twitter.com/adonoho

"When you can't imagine how things are going to change,
that doesn't mean that nothing will change.
It means that things will change in ways that are unimaginable."
Bruce Sterling, January 02, 2009

[Matt Blair]

Hi Zardon,

Core Data is really good for what it does on the device. That last
phrase is the key: Core Data doesn't know that the rest of the world
exists, which is kind of strange for a data persistence layer on a
mobile device in 2011.

I haven't embedded Couchbase in an app yet, but I have several apps
that use Couch for cloud data storage. For me, the promise of
Couchbase on iOS is the ability to maintain a shared dataset in the
cloud, and then replicate it down to Couchbase on the phone for better
performance when cellular data speeds aren't good enough, or when the
device is offline. Let your users make changes, and replicate those
changes back up so everyone else can see them the next time they sync.

Core Data has no concept of this, so you have to build your own web
service (or use something like Couch) to manage it all, and you have
to roll your own sync to and from the device. With Couch on the
device, you can just use replication.

Another use case I'm looking at is syncing private data between
devices: you have a Universal app, and your users expect to edit on
the phone and have the change appear on their iPad. Or they add an
item in a desktop app at work, and expect it to be on the iPhone on
their evening commute, and available in their desktop app at home
after dinner.

If you are using Core Data, you could use the same model files for
your iOS apps and your OS X desktop application, which allows for some
code re-use, but that's about the extent of it. You have isolated data
stores on each device, and again, you have to code a solution to
manage changes between all of them. Doing this well is non-trivial.
(The story of Cultured Code and Things cloud-sync may or may not be a
good example, depending on your perspective.)

Using master-to-master replication with Couch seems like it could be a
great option here. (I think this is similar to how Ubuntu uses Couch,
but I could be wrong.)

Customers expect "edit once, magically appear everywhere" and Couch
can help make that magic happen with a lot less work than Core Data
alone.

And as Andrew mentioned, schema flexibility is a big plus for Couch,
too, especially during the development phase.

Schema migrations in Core Data can be tricky. Even when they go well,
they eat up your time. And if you are using SQLite for storage with
Core Data, Apple considers their SQLite schema for Core Data 'private'
and subject to change, and suggests that you write Objective-C code to
instantiate and save all objects to your store. The actual schema is
fairly well reverse-engineered, but building your own store with tools
of your choice might not be future proof. Bottom line: It's usually a
lot easier to import, restructure and move data around with Couch and
JSON than it is with Core Data and Objective-C.

Matt

--
http://mattblair.net

[Jonathan Wight]

To be honest it isn't useful to compare CouchDB directly to CoreData. They are - or at least can be - two different things. CouchDB on iOS doesn't provide the niceties that CoreData provides. For example - CouchDB doesn't provide an object-graph that makes interacting with the data so (relatively) painless in CoreData. CouchDB on the other hand provides replication with the "cloud".

I think CoreData can exist over the top of CouchDB and that's what I do in AnythingBucket (a simple CouchDB/CoreData based Geo tracker app). CoreData provides. At the moment I don't think it's possible to make this CoreData "just work" on top of CouchDB but this might be possible in the future (in fact pretty sure it can work like this on 10.7 - and there's hope this ability will come to iOS eventually).

Jon.

[Jonathan Wight]

I suppose a link to AnythingBucket would be useful:

https://github.com/schwa/AnythingBucket

Jon.

[zardon]

Hey all.

Thanks for your replies and answers. They were very clear, gave good
context and I feel much better understanding about it. I felt my
question might help orient new users to Mobile Couchbase a bit
quicker, and I'm glad the community was able to explain things more
succinctly, which is refreshing.

I might play around with Mobile couchbase. I'm using Core data for a
game/app that acts as a local only database; but I can certainly see
the attraction of a framework/platform which allows you to do the
whole cloud data storage.

Just one last question, just a clarification. Can you use Mobile
Couchbase without using the cloud part. Can you use as a total
replacement to Core Data?

Sorry if I am laboring the point.

Thank you.

[Jonathan Wight]

Not really. As I mentioned in my last post CouchDB doesn't provide the niceties you'd want. While you could use CouchBase as a purely local solution it wouldn't buy you much. And the costs (memory usage, risks of using an extremely immature project, project complexity, possible risks with Apple Store acceptance) outweigh the benefits in my opinion. If you need CoreData my advice would be to just use CoreData. CouchDB's reason for being is the cloud.

The CouchDB guys may or may not agree with me here though.

Sent from my iPad

[J. Chris Anderson]

On Thursday, May 12, 2011 11:34:14 PM UTC-7, Jonathan Wight wrote:

Not really. As I mentioned in my last post CouchDB doesn't provide the niceties you'd want. While you could use CouchBase as a purely local solution it wouldn't buy you much. And the costs (memory usage, risks of using an extremely immature project, project complexity, possible risks with Apple Store acceptance) outweigh the benefits in my opinion. If you need CoreData my advice would be to just use CoreData. CouchDB's reason for being is the cloud.

It is more subtle than that. The cloud is optional. For instance Couchbase Mobile would be killer for device-to-device syncing an app between iPhone, iPad, and Mac versions. Or multi user near-realtime iOS apps using GameKit for discovery.

It's just a bonus feature that you can replicate that data to a cloud instance and wrap an ajax interface around it so users can get to their data even when they are away from their devices.

[Joshua Partogi]

Hi Guys,

Just like Zardon, I am also interested to exploit Mobile couchbase for our next mobile apps.

My question is:

- Do we need to embed the whole iOS Couchbase with our apps? If so, how big the size would it be? I don't want to end up distributing a large size apps just because we need to embed iOS Couchbase in our apps.

- Does user need to install erlang to be able to run iOS Couchbase?

- Does the same thing (Mobile couchbase) also exists in the Android and Blackberry world?

Sorry for the very vague questions guys. Eveerything is still up in the air for me. Thanks for your assistance.

[Dave Cottlehuber]

On 21 May 2011 18:06, Joshua Partogi <joshua....@gmail.com> wrote:
> Hi Guys,
> Just like Zardon, I am also interested to exploit Mobile couchbase for our
> next mobile apps.
> My question is:
> - Do we need to embed the whole iOS Couchbase with our apps? If so, how big
> the size would it be? I don't want to end up distributing a large size apps
> just because we need to embed iOS Couchbase in our apps.

Yes, however reducing footprint is likely to be the next thing once
functionality is sorted (reading Chris' mind here).

> - Does user need to install erlang to be able to run iOS Couchbase?

Not directly, but it is included in the app bundle.

> - Does the same thing (Mobile couchbase) also exists in the Android and
> Blackberry world?

Yes for android - I'm not sure of the status. Hopefully somebody else
can cover that.

A+
Dave

[J. Chris Anderson]

On Saturday, May 21, 2011 2:52:38 AM UTC-7, Dave Cottlehuber wrote:

On 21 May 2011 18:06, Joshua Partogi <joshua....@gmail.com> wrote:
> Hi Guys,
> Just like Zardon, I am also interested to exploit Mobile couchbase for our
> next mobile apps.
> My question is:
> - Do we need to embed the whole iOS Couchbase with our apps? If so, how big
> the size would it be? I don't want to end up distributing a large size apps
> just because we need to embed iOS Couchbase in our apps.

Yes, however reducing footprint is likely to be the next thing once
functionality is sorted (reading Chris' mind here).

Thanks Dave, good answers. 

I am targeting 5mb for optimizations of the current implementation. Today it is 13mb.

My next step will be making JavaScript optional, as that is roughly half the current payload. Then you'd write your map reduce in Erlang, but a typical map function is  like 5 lines long so I hope that is cool. We want to  have a C-bridge so you can write Map Reduce in ObjC.

As soon as Apple makes the JavaScript runtime on the phone available to us, we'll be able to add JavaScript back into our default package without incurring such a performance cost. 

> - Does user need to install erlang to be able to run iOS Couchbase?

Not directly, but it is included in the app bundle.

The user should never know there's anything Couch about it. They just get magic Sync.

 

> - Does the same thing (Mobile couchbase) also exists in the Android and
> Blackberry world?

Yes for android - I'm not sure of the status. Hopefully somebody else
can cover that.

A+
Dave

We have had "CouchDB" in the Android marketplace for almost a year. We are working on a Mobile Couchbase Android release in the next few months.

Chris

 

[Joshua Partogi]

Hi Chris,

Thank you for the answer. If it can be optimised down to 5MB I think
that would be awesome because 13MB still seems to be fairly big. Is
there any roadmap for this?

Looking forward for the Android Couch build. Will this be announced on
the website too?

Thank you in advance for the answers.

Kind regards,
Joshua

[J. Chris Anderson]

Joshua,

The roadmap is discussed in a thread called "Roadmap". The highlight of the plan to shrink to 5MB is by making JavaScript support optional. Currently we ship the Spidermonkey JS engine as part of Mobile Couchbase. It is more than 1/2 the payload, so if users are willing to write Map Reduce in Erlang instead of JavaScript they can have an instant fix. In the longer term we want to add a bridge to C, so that you can write your Map Reduce in ObjC.

Also as part of shrinking the package, there is room to create a smaller version of the Erlang VM, although that is a bit more involved.

Anyone who is interested in these things, patches definitely welcome!

Chris

[c1sc0]

FYI: in the current app I'm building I've got the whole app (including
Couch) down to 8.8MB, well below the 20MB Apple 3G limit.