# couchdb Apache CouchDB is a web-oriented database that stores JSON documents, provides HTTP access, supports JavaScript querying, and enables incremental replication. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## ApacheCon Budapest 2014 DevFeed: [ApacheCon Budapest 2014]() Original publisher: [Read original article]() Author: mick Published: 2014-11-25T13:00:00Z Content type: opinion Language: en Sources: [Finn.no]() Topics: [Hadoop](), [Apache Spark](), [Docker](), [hdfs](), [Apache Cassandra](), [Streaming](), [couchdb](), [Data structures]() Tags: [apache](), [cassandra](), [couchdb](), [data-structures](), [docker](), [hadoop](), [hdfs](), [spark](), [streaming]() ### AI overview A firsthand account of ApacheCon Budapest 2014 discusses Apache communities and several technologies, including Docker, Spark, Cassandra, CouchDB, Hadoop, Mesos, Aurora, YARN, Solr, and OpenOffice. It highlights considerations around scalability, testing, streaming, production utilisation, and data processing. ### Source excerpt Last week was Europe's ApacheCon, held in Budapest. A refreshingly "laid-back and no-nonsense" conference free from the douchebaggery that comes from big sponsors and marketing. This year it was held in the awesome 5-star Corinthia Hotel, and consisted of a welcoming and cheerful vibe, a place for apache members, committers, and all, to get together and better know each other. Apache continues to grow as the foundation for strong communities building trusted open sourced solutions, for running half the internet, and providing a substantial amount of code to your java stack. Some hot topics were Docker, Mesos, Spark, Cassandra, CouchDB, Hadoop, Solr, OpenOffice, and the need for greater diversity in our communities. Spark is all the rage because of its brevity and simplicity, but isn't really a complete solution yet because it doesn't scale in many situations. Docker is awesome, and looks to take over the testing domain, but it remains limited and out of production as long as it has no network stack implementation. There was a very cool demonstration of Mesos and Aurora increasing production utilisation, even allowing in quiet periods for development/testing servers to come in. The next release of YARN (2.6) will see support for long-lived services, whereby we can transform many of our hadoop jobs with very little effort into true streaming solutions. YARN will also be able to deploy docker containers through its clusters, this could be a very nice solution for our batch jobs. Putting these together and you see that the technical separation between streaming and aggregating solutions fades away and it really just boils down to what data structures you solve each use case with. Talking with a hadoop committer it came to light that FINN could be running the fastest hadoop cluster that they know of, given HDFS runs on SSDs and is dedicated just for hadoop internals. Of no surprise Solr dealt a lot with scaling and performance, while Cassandra presented use-cases from ac ## Rethinking the limits on relational databases DevFeed: [Rethinking the limits on relational databases]() Original publisher: [Read original article]() Author: Map Published: 2014-01-24T20:55:56Z Content type: opinion Language: en Sources: [Craig Kerstiens]() Topics: [Databases](), [NoSQL](), [migration](), [MongoDB](), [couchdb](), [Object-relational mapping](), [JSON](), [PostgreSQL](), [Django](), [Rails]() Tags: [couchdb](), [databases](), [django](), [json](), [migration](), [mongodb](), [orm](), [postgres](), [postgresql](), [rails](), [relational-databases]() ### AI overview This opinion argues that useful ideas associated with schema-less databases could be applied to relational databases. It focuses on reducing migration friction through frameworks or ORMs and on supporting document-like JSON storage in relational systems. ### Source excerpt Theres a lot of back and forth on NoSQL databases. The unfortunate part with all the back and forth and unclear definitions of NoSQL is that many of the valuable learnings are lost. This post isn't about the differences in NoSQL definitions, but rather some of the huge benefits that do exist in whats often grouped into the schema-less world that could easily be applied to the relational world. Forget migrations Perhaps the best thing about the idea of a schemaless database is that you can just push code and it works. Almost exactly five years ago Heroku shipped git push heroku master letting you simply push code from git and it just work. CouchDB and MongoDB have done similar for databases... you don't have to run CREATE TABLE or ALTER TABLE migrations before working with your database. There's something wonderful about just building and shipping your application without worrying about migrations. This is often viewed as a limitation of relational databases. Yet it doesn't really have to. You see even in schema-less database the relationships are still there, its just you're managing it at the application level. There's no reason higher level frameworks or ORMs couldn't handle the migration process. As it is today the process of adding a column to a relational database is quite straightforward in a sense where it doesn't introduce downtime and is capable of letting the developer still move quickly its just not automatically baked in. # Assuming a column thats referenced doesn't exist # Automatically execute relevant bits in your ORM # This isn't code meant for you to run ALTER TABLE foo ADD COLUMN bar varchar(255); # This is near instant # Set your default value in your ORM UPDATE TABLE foo SET bar = 'DEFAULT VALUE' WHERE bar IS NULL; ALTER TABLE foo ALTER COLUMN bar NOT NULL; Having Rails/Django/(Framework of your choice) automatically notice the need for a column to exist and make appropriate modifications you could work with it the same way you would managing a doc ## Automatically compact CouchDB databases in version 0.11.x DevFeed: [Automatically compact CouchDB databases in version 0.11.x]() Original publisher: [Read original article]() Author: Tom Published: 2012-11-08T00:00:00Z Content type: tutorial Language: en Sources: [Tomasz Gągor]() Topics: [couchdb](), [Databases](), [Script](), [Bash](), [cURL](), [HTTP](), [JSON]() Tags: [bash](), [couchdb](), [curl](), [daily](), [databases](), [http](), [json](), [linux](), [performance](), [post](), [script]() ### AI overview This tutorial presents a Bash script that can run from cron to compact all CouchDB databases on version 0.11.x. It states that regular compaction helps manage database growth, performance, and space usage. ### Source excerpt CouchDB databases on version 0.11.x swell very fast. They should be compacted daily for best performance and space usage. Here is my script that could be run in cron and will compact all databases: #!/bin/bash IP="10.0.0.121" DBS=`curl -sS -X GET http://$IP:5984/_all_dbs | sed -r "s/([,\"[])|(\])+/ /g"` for d in $DBS; do curl -H "Content-Type: application/json" -X POST http://$IP:5984/$d/_compact done More informations about compacting could be found here external link (also for version 1.2.x). ## CouchDB - Instalacja i wstępna konfiguracja DevFeed: [CouchDB - Instalacja i wstępna konfiguracja]() Original publisher: [Read original article]() Author: Tom Published: 2012-06-08T00:00:00Z Content type: tutorial Language: pl Sources: [Tomasz Gągor]() Topics: [couchdb](), [NoSQL](), [HTTP](), [MongoDB](), [Ajax](), [WebSocket]() Tags: [couchdb](), [debian](), [http](), [linux](), [mongodb](), [nosql](), [proxy](), [reverse-proxy](), [tcp]() ### AI overview This Polish tutorial explains installing and initially configuring CouchDB for storing uploaded files in web applications. It discusses CouchDB's HTTP-based access model, use behind a reverse proxy, AJAX access, TCP NODELAY for small-file responses, and record identifier design. ### Source excerpt Gdy tworzymy pierwszą aplikację webową, która umożliwia upload plików przeważnie lądują one lokalnie w pewniej lokalizacji. Gdy druga aplikacja potrzebuje dostępu do tych plików wystarczy podać ścieżkę. Problemy zaczynają się gdy aplikacji jest kilka i rozmieszczonych na kilku serwerach. Można korzystać z sieciowych systemów plików ale to często nie jest zbyt wygodne - ciężko odpowiednio ustawić uprawnienia by pewne aplikacje miały dostęp do zapisu plików a inne nie, trzeba skonfigurować dany katalog w kilku miejscach w konfiguracji serwera WWW aby serwować pliki itp... ## CouchDB + Ext as a Replacement for Server Code DevFeed: [CouchDB + Ext as a Replacement for Server Code]() Original publisher: [Read original article]() Published: 2010-06-08T00:00:00Z Content type: opinion Language: en Sources: [Tim Kellogg]() Topics: [couchdb](), [web applications](), [Database](), [JavaScript](), [JSON](), [business logic](), [client]() Tags: [business-logic](), [client](), [couchdb](), [javascript](), [json](), [web-apps]() ### AI overview The article examines whether a web application can move its business logic into the browser while using CouchDB as a web service instead of server-side code. It discusses CouchDB's schema-free document model, JSON documents, relationship modeling, object persistence, and potential scalability, while noting that many-to-many relationships may be more complicated. ### Source excerpt In a previous post about ExtJS I mentioned the possibility of developing a web application that runs entirely inside the browser and doesn't require any server side code. The idea stems from a) ExtJS is a fully capable widget framework and b) CouchDB is accessible via a web service. At least 80% of web apps are just a HTML interface with a database back-end and a little bit of business logic. So why can't we move all that business logic to the browser, setup calls to a CouchDB web service from the browser and 86 the server-side code? In this post I'm going to analyze this question and see if it's realistic. In a follow up post I'm going to analyze this same question from a business standpoint.A Database Void of SchemaCouchDB is a document oriented database, meaning that it doesn't have tables and keys like you do in relational databases. It just has one big space full of documents. A document in CouchDB is a JSON object, so its attribute values can be strings, booleans, numbers, lists, or other objects (documents). Having complex "rows" means that many of your relationships that you would normally form by using a second table and a primary-foreign key set is simplified down to embedding a list. Consequently, 1-to-1 and 1-to-many relationships are native to the database and require no extra thought or planning. Many-to-many relationships are more complicated, so this approach might break down if you require too many of these. Some other oddities in relational databases like versioning and pivot tables come native with CouchDB. Since the bulk of our database requirements are made easier with CouchDB, querying is going to be generally simpler.The other great thing about having a document formatted in JSON is that you can save any JavaScript object directly to the database. You could save the state of an Ext widget or a whole form. It's like simplified object serialization for the browser! This is definitely a killer argument for making fat client apps with Ext.But What