Something like Fuuton for touchdb?

[Gaara]

I was just wondering if there was anything like fuuton for touchdb so that i can view the contents of the db and interact with it thru a gui?

[Aaron Vegh]

Hi there,
There isn't, but you can dump the content of your app out of Xcode and then use a SQLite client of your choice to view the database. Since I have Firefox, I use a free plugin called SQLite Manager. It ain't pretty, but it works.

Cheers,
Aaron

Sent from my iPad

[Nicolas Lapomarda]

If you're using the Mac version, there's TouchDBViewer.
https://github.com/couchbaselabs/TouchDBViewer

Nico

[Akash]

No Nico, i am not using the mac. I already went thru that app but it doesn't look like it is useful for me thats why i went ahead with this.

@Aaron, i'm using Android, any idea where the file gets saved?

Slightly off topic, but i couldn't find any discussion on why a conventional database has been used to "simulate" nosql, in the case of touchdb atleast.

--
Adrenaline Junkie

[Jens Alfke]

On May 13, 2012, at 9:01 AM, Akash wrote:

Slightly off topic, but i couldn't find any discussion on why a conventional database has been used to "simulate" nosql, in the case of touchdb atleast.

It's in the FAQ:

Q: Why SQLite instead of a B-tree engine like Berkeley DB or Kyoto Cabinet?

A: Largely because SQLite is already available as a shared library on every platform we’re interested in; this keeps our code size down and simplifies the build process.

Additionally, both Berkeley and Kyoto have GPL-like licenses that are less friendly to commercial developers (especially iOS developers) and incompatible with the Apache license of TouchDB itself.

And in the "Why TouchDB?" document:

Storage Engine:

CouchDB contains a very clever B-tree engine with a lot of valuable characteristics. But rewriting it in a new language would be a big undertaking. There are a lot of other storage engines out there (Berkeley DB, Kyoto Cabinet, LevelDB…) but we’d have to consider their code size and licenses.

In the end, I think SQLite is the best choice. It isn’t a perfect fit for TouchDB’s data model, but you can’t beat its code size (effectively zero since it’s already incorporated into every OS). It obviously doesn’t scale up especially well, but that’s not an issue for mobile apps. SQLite is already very widely used as the persistence layer for a lot of apps, especially considering that Apple’s CoreData framework uses it.

SQLite is of course B-tree based, but its low-level B-tree API is considered internal and not recommended for developer use. Instead we can just use the regular SQL API to define tables and indexes for what we need. This has the advantage of moving a fair bit of the database logic intoSQL, making it cross-platform and reducing the size of the source code.

[Marty Schoch]

Currently in TouchDB on Android you can place the files anywhere you want.  The grocery sync application puts them in /data/data/com.couchbase.grocerysync/files

You can browse the database with the sqlite3 command inside adb shell.  Using adb pull to get the files and accessing them on your host machine with other tools may not work because we use custom collators.

Marty

Sent from my iPhone

[Jens Alfke]

I don't use Android so I don't know for sure, but if there's a Mac utility that lets you mount an Android device's filesystem (like iExplorer for iOS), you could use the TouchDB viewer with that.

But it's not too hard to make sense of a TouchDB database with the 'sqlite3' tool. The schema is documented. A query to get the contents of the document with ID "MYDOCID" would look like:

select json from revs, docs where docid='MYDOCID' and revs.doc_id=docs.doc_id and current=1;

(that was typed directly into Mail so it might have syntax errors…)

—Jens

[Akash]

Thank you Marty.

--
Adrenaline Junkie

[Gaara]

I finally went ahead and installed this plugin called SQLite browser in eclipse, which sits above DDMS, so that i can view the file without viewing it. It covers my basic necessity of viewing data with ease so i'm happy :)

[Gaara]

On Sunday, May 13, 2012 9:57:30 PM UTC+5:30, Jens Alfke wrote:

On May 13, 2012, at 9:01 AM, Akash wrote:

Slightly off topic, but i couldn't find any discussion on why a conventional database has been used to "simulate" nosql, in the case of touchdb atleast.

It's in the FAQ:

Q: Why SQLite instead of a B-tree engine like Berkeley DB or Kyoto Cabinet?

A: Largely because SQLite is already available as a shared library on every platform we’re interested in; this keeps our code size down and simplifies the build process.

Additionally, both Berkeley and Kyoto have GPL-like licenses that are less friendly to commercial developers (especially iOS developers) and incompatible with the Apache license of TouchDB itself.

From what i can judge, an object is persisted inside sqlite right? in terms of actually storing data?  

[Jens Alfke]

On May 13, 2012, at 11:58 PM, Gaara wrote:

> From what i can judge, an object is persisted inside sqlite right? in terms of actually storing data?

Documents are stored in SQLite, yes. There’s complete documentation of the schema in the wiki.

—Jens