tony_landis's comments

Here is the reference for update handlers for anyone wanting to check it out:

http://docs.couchdb.org/en/latest/ddocs.html#update-function...

It still requires writing code, and moving it into the database.

Once that is done, how do you call that function against an arbitrary list of documents and pass the new values to it without writing even more code somewhere?

This workflow of putting code/logic in the db is that it is forcing developers out of their preferred development environment, workflow, and most likely language.

Not to mention the fact that debugging all these couchdb functions and map/reduce calls becomes a nightmare. And testing - not sure how that could be done efficiently.

All of this this slows development.

It is possible to implement some web apps completely in static html, js, and couchdb, eliminating the need for anything server side. In those cases, couchdb is one of a kind.

I think the kind of thing you are doing is the sweet spot for couch. Perhaps over time it will be less so, but I now I think it is pretty unique.

Good points. Replication is certainly not painless to setup, and I've had trouble with continuous mode simply failing. I'm sure those warts will be worked out though.

Lucene and Elastic Search go a long way, it is just one more service to configure and maintain. Thats been an annoyance for me. If Lucene could be built right into couchdb that would be a major improvement.

However, that still doesn't let me cherry pick the values I want from a document. When the app is in a dynamic language, the cost of deserialization can add up.

Building some kind of xpath expressions to pull out specific parts of the doc would free up developers from spending as much time writing views, and would likely be much more performant to have that operation take place server-side. Maybe that should be an Elastic Search feature though and not Couch.

I think it was Rich Hickey that said the document database is the worst of them all, because you are now married to that structure.

Having used Couchdb in production for two years, I have to agree with his analysis, and offer my own opinion that Couchdb is highly overrated. Not because it is not a good implementation of a document style database, but because the document store itself is not a good match for most use cases.

If the only requirement is a replicated JSON document store, it may work OK for you. But so would Riak, Postgres and some others.

If you need to update the data in those documents or ever need to query the data in ways you did not initially envision, you will quickly find yourself missing features which even traditional SQL databases are very good at. Development is slower.

Writing map/reduce for queries seems particularly cumbersome, particularly if you prefer not to use Javascript. And you have to plug them into a textarea in a webpage interface, or manually put them into Couchdb over http using curl or some library that abstracts this away. Either way it is a degree of separation that makes the data feel more out of reach than through a console interface like psql or mysql.

Consider the scenario where you want to update the value in an attribute on several thousand, or even just several documents that match some criteria. In SQL, you would simply jump in the console and in a few seconds or minutes complete that as a transaction with something like:

> update table set col=val where criteria.

There is no such feature in Couchdb. You will need to write code to filter and fetch each matching document, manipulate it as needed, then write the entire thing back. All to update a few bits that hopefully were not nested too deep as that really increases the complexity of the code you will need to write.

As memracom stated, the replication is not perfect. My experience even on a low latency network is the only safe way to ensure a client can immediately read back what they just wrote is to pass them through the likes of haproxy and use a sticky session. Otherwise you have a good probability of getting a 404 after a POST (create) or stale data after a PUT (update).

So for what it is worth, here is my advice on choosing a database from an ease of development standpoint:

1) has as many features as you can, even if you don't need them initially 2) has top notch libraries for your language / framework 3) has relation awareness - do not denormalize unless you must 4) supports consistency 5) supports in place updates - easily filter and change values (doesn't apply to Datomic) 6) has tools to make schema changes / reshaping data is easy, and can be done online

Maybe 2 years ago Couchdb was a great solution. But with memory and ssd storage being so cheap and so much innovation with traditional and NoSQL DBs, I don't foresee myself deploying Couchdb again. If I did need a place to dump some semi-structured data, I find Amazon's hosted offerings more attractive.

Very nice work and a worthwhile project!

Indeed. The whole reason for the existence of all these frameworks riot is being compared is to to simplify development.

Angular has no dependancies. Knockout also has no dependancies, so it's actually 13k > than riot.

For anyone who really serious about going minimal, here are some alternatives to jquery to build on.

9.7kb http://zeptojs.com/ 3.4kb https://github.com/rpflorence/snack 5.0kb https://github.com/julienw/dollardom/ 10kb http://xuijs.com/ <1kb https://github.com/honza/140medley

What a riot!

I guess I don't understand why Datomic's entity id wouldn't work as your auto-incrementing id.

If you wanted something else, then why not just use a UUID to avoid relying on the DB?

Or if you are using a RDMS like postgres for datomic's underlying datastore, just manage a seq directly there.

One thing I have learned is trying to use one tool for every problem just creates a lot of headache.

Were you already experienced with Clojure? I am just starting out with Clojure, so datomic being such a young database makes things challenging.

I am curious if you could expound on #3. I am starting a migration myself.

It got me within 4 years

Hi Michael, your site looks pretty slick. Reminds me of airbnb a bit.

The way I understand your marketing pitch, you hate expedia and are going to undercut their prices. I compared one of the top hotels you list in la fortuna with expedia's rates and they are matching tripfab. Seems like their cancellation terms are more lenient also.

http://d.pr/i/LFjl http://d.pr/i/oe1s

Actually, the rooms are shown twice and they could actually be beating your rate, hard to tell. When I tried to proceed to get the tax breakdown I got an error page.

Expedia has a lowest rate guarantee, so how can anyone really hope to undercut them any way?

--

For reference:

http://www.expedia.com/Arenal-Volcano-Region-Hotels-Arenal-K...

https://tripfab.com/en-US/costa_rica/la_fortuna/arenal_kioro...

Very nice. Have you checked out The Hit List?

One of the main reasons I chose it was it keyboard friendly controls.

One suggestion - in edit mode, the a and d keys are much more intuitive for indenting a line. Also, shift + j/k is more intuitive for moving lines than ctrl + arrow keys.

I guess my vim-brain is showing through ;)

No vim mode support?

Would love an invite: tony.landis at gmail

Thanks! Looks like results may vary based on the problem set, I will have to check out both languages

Thanks I will check those out.

monitor and laptop both elevated, with magic mouse and keyboard below

I think they will still have a solid userbase, but will be far less hyped.

Anyone here have plans to attend? I am considering...

Sean, that sounds great, I just shot you an email. Looking forward to your response.