$ grep -r Tag: «couchdb»

Highlights

• Refactored the internal request pipeline in CouchDBClient to use cleaner async/await-style flows and reduce duplicated response handling logic.
• Improved buffering and decoding paths for raw and typed requests, with a focus on safer EventLoopGroup execution and better performance in response processing.
• Expanded test coverage around EventLoopGroup-backed request execution, including raw and typed get, raw and typed find, attachment download, Mango index listing, and Mango query explanation.
• Refreshed user-facing documentation across the README, DocC articles, and tutorials.
• Updated documentation tooling for newer DocC workflows, including Markdown export support.

API and Behavior Improvements

• Added and refined EventLoopGroup support across more CouchDBClient request paths.
• Improved internal error-handling paths and response decoding behavior for CouchDB operations.
• Simplified request helper layering and reduced duplicated request/response processing code.
• Improved attachment-related behavior and accompanying tests.
• Added visionOS to supported platforms in the package manifest.

Documentation

• Fixed and refreshed README examples for CRUD and Mango query usage.
• Updated DocC landing pages to better reflect the current API surface.
• Corrected the Advanced Mango Query tutorial snippets to match the current typed query API.
• Corrected Vapor tutorial examples.
• Fixed Hummingbird tutorial package setup and dependency snippets.
• Updated buildDocs.sh to support:
  • configurable output and hosting base path
  • static hosting content embedding
  • experimental Markdown output
  • Markdown manifest generation
• Added a post-processing step in buildDocs.sh that injects a relative Markdown link into generated DocC HTML pages.

Tooling and Dependencies

• Updated package dependencies in Package.resolved.
• Updated the Ubuntu build workflow Swift version matrix.

CouchDB Client on GitHub | Documentation with examples and tutorials.

Star Fork

Recently, I've implemented a feature that I wanted to add to the CouchDB Swift client for a long time. It's Mango Queries support. Finally, it is done in 2.3.0. Feels like the last remaining big feature.

Changelog:

• Introduced a robust and type-safe MangoQuery API for building complex selectors, projections, sorting, and pagination in CouchDB.
• Added support for specifying indexes via useIndex in queries to optimize performance.
• Added first-class support for uploading, downloading, and deleting document attachments (files/images).
• Comprehensive Attachments API test suite ensures reliability for file operations.
• Added models and API for creating, listing, and managing Mango indexes (MangoIndex, IndexDefinition).
• Tutorial and code samples for creating indexes are now included in documentation.
• Added support for CouchDB Mango _explain endpoint via MangoExplainResponse to inspect how queries are executed and which indexes are used.

CouchDB Client on GitHub | Documentation with examples and tutorials.

Star Fork

Recently, I've been playing a lot with AI agents, and it really inspired me to update my projects. Playing with real-life tasks makes it more fun.

Couchdb Swift client lib

There are 2 new releases of couchdb-swift library. Copilot kindly added more unit tests to the library to cover more use cases. Mostly failures. I still had to tweak a lot manually, but it gave me some ideas. So I've added more error handling in these 2 recent releases. Also, it found a couple of minor bugs and fixed them, reviewed my PR, and suggested some improvements. Far from being perfect yet, but still pretty impressive.

Release Informer Bot for Telegram

At some moment, I found that Copilot Agent is available for my account, and I can simply start with an issue on GitHub, assign it to the agent, and see what it will do. I've started with a request to update the README for Release Informer Bot with some nice details about how it works and how to set it up.

After the agent finished the updated README, it gave me another idea. Setting up might be automated. So I've opened Visual Studio Code and asked the Copilot agent to add automatic creation of the required database and set it up with the required CouchDB indexes.

It also did a good job, but it still required some manual tweaks and changes. And during that, it led to one more release of the CouchDB client lib because I wanted to rely on a proper "not found" error.

It's hard to tell how much time Copilot saved me. But definitely a lot. Including my favorite automatic string translations. Hopefully, that will inspire me to ship more.

Recently, I’ve released a few new versions of the CouchDB client for Swift. The latest version is version 2, and it includes several key changes:

• Updated the minimum required Swift tools version to 6.0.
• Adopted Swift Concurrency. CouchDBClient has been updated to be an actor.
• Renamed the library from couchdb-vapor to couchdb-swift to better reflect its purpose as a general CouchDB client for Swift, beyond Vapor-specific use cases.
• Made some changes to the initializer. Instead of passing a lot of parameters, it now accepts a Config structure.
• You can pass your own HTTPClient instance to be used in the client.
• Added translations for error messages.
• Introduced a dedicated tutorial for integrating CouchDBClient with the Hummingbird server-side framework.
• Added a shutdown() method to properly release resources associated with the HTTPClient.

CouchDB Client on GitHub | Documentation with examples and tutorials.

Star Fork

And here we go, one more new version of the CouchDB client library. After the recent post about 1.4.0, Swift on Server released a new version of async-http-client that includes a new implementation of the client singleton. Now it's HTTPClient.shared, so I've updated the CouchDB library to adopt that change. This also means that you no longer need to call httpClient.syncShutdown() if the singleton is used. Additionally, they've bumped the minimum Swift version to 5.8 (which I aslo did in version 1.4.0 of the CouchDB client library). So, I'm keeping the library up to date.

Changelog:

• Bumped the minimum version of async-http-client to the new 1.21.0. If you can't use it in your project, you can still stay on 1.4.0.
• The library will now use HTTPClient.shared (new in async-http-client 1.21.0) internally for requests if no EventLoopGroup is provided.
• No more internal calls for httpClient.syncShutdown() in case of HTTPClient.shared usage.

CouchDB Client on GitHub | Documentation with examples and tutorials.

A new version of CouchDB Client has been released:

• The library migrated from HTTPClient.Response to HTTPClientResponse, which is similar to HTTPClient.Response but used for the Swift Concurrency API. It also migrated from HTTPClient.Body to HTTPClientRequest.Body. These changes impact the get and find methods. Old methods are marked as deprecated, please refer to the documentation for the updated methods.
• The minimum Swift version is now 5.8.
• The CouchDBRepresentable protocol is now marked as Codable.
• Additionally, a new data model called RowsResponse has been added. It accepts a generic CouchDBRepresentable type, making it easier to retrieve rows from a database. For example:

  let decodeResponse = try JSONDecoder().decode(RowsResponse<MyApp>.self, from: data)

• Lastly, there have been small improvements in the documentation and tutorials.

CouchDB Client on GitHub | Documentation with examples and tutorials.

Recently, there have been a couple of new releases for my Swift CouchDB library. Here are the recent changes:

• dateDecodingStrategy and dateEncodingStrategy can now be passed as parameters for get, update and insert methods.
• Added a check to handle expired authentication cookies.
• Comparing the set-cookie header in the response as lowercased.
• Introduced new methods to utilize the _find API, allowing you to find documents using a declarative JSON querying syntax
• Fixed an issue where the update method didn’t use dateEncodingStrategy parameter.

CouchDB Client on GitHub | Documentation with examples and tutorials.

Just a small update for Swift CouchDB client lib with couple new methods that I needed by myself:

• Added a new method to create a database [docs].
• Added a new method to delete a database [docs].
• Added a new method to check if a database exists [docs].
• Every request handles unauthorised errors now.
• CouchDBClientError model has a description text now.

CouchDB Client on GitHub | Documentation with examples and tutorials.

Couple months ago I started learning Apple's DocC tool that generates documentation from your source code. I've decided to use as many features as possible so I took my small lib CouchDB Client and added docs to every method including usage examples that Xcode will show in the autocomplete popup. As it often happens, during adding docs and examples I found that many things in the library can be done in a much better way. So I've updated existing methods and added some more that can take a doc as a param and use generic types.

Next step was tutorials. Apple allows devs to create exactly the same tutorials as they have for SwiftUI on their own website. So I've added a couple. They're also part of the repo on GitHub.

Pretty sure that I've spent more time on the documentation than on the lib itself but I hope it's worth it.

CouchDB Client on GitHub | Documentation with examples and tutorials.

Finished new version of Swift CouchDB client. Now it's using only async-http-client as a dependency to make http/https requests. Can be used with Vapor 4.

Available on Github: https://github.com/makoni/couchdb-swift

A few days ago I wrote my first Node.js tool. I wrote it only partly for myself, because for me it is not very relevant yet, but for some people it very much is.

The tool is for CouchDB. Since CouchDB keeps document revisions after changes and deletions and does not always clean them up, a database can grow like crazy. For example, for the guys who need this tool right now, something that should weigh 6 GB weighs 50-60. Maybe they started something somewhere or messed something up, changed and wrote a ton of stuff into the database, and that blew up its size. So, overall, it is easier to just create a new clean database and move all live documents there.

The tool simply takes all documents from 1 database in CouchDB and puts them into another one. For now it works rather crudely: it grabs all documents in one shot and then inserts them into the database one by one. For databases with a relatively small number of documents it works fine, but if there are something like 80 thousand documents, fetching them on my computer took about 4-5 minutes. So I will rework it soon so that it pulls documents in batches and writes them to the database sequentially instead of asynchronously.

But it is already usable. You can embed the tool into your own Node.js project, for example.

In the console:

npm install node-couchdb-mover

In code:

var mover = require('node-couchdb-mover');
mover.moveDocuments('dbName1', 'dbName2');

It can also be used directly from the console:

npm install -g node-couchdb-mover
couchdb-mover --from=dbName1 --to=dbName2

And, as expected, here are the sources on GitHub and the package on npmjs.org.

Translation of an answer on stackoverflow.com to the question about the differences between CouchDB and Couchbase.

I think there are some essential differences between CouchDB and Couchbase Server that need to be pointed out.

I will not write about the advantages of switching from CouchDB to Couchbase Server because those are described pretty much everywhere (see The Future of CouchDB by Damien Katz or Couchbase vs. Apache CouchDB by Couchbase). Instead, I will try to enumerate features of CouchDB that you will not find in Couchbase Server.

Names and confusion

There is CouchDB, CouchIO, CouchOne, Couchbase, Couchbase Server, Couchbase Mobile, Couchbase Lite, CouchApps, BigCouch, Touchbase, Membase, Memcached, MemcacheDB... all different and yet related, obviously not only by name.

First, there was CouchDB, a database created by Damien Katz, a former IBM developer. Its official name changed to Apache CouchDB after it became an Apache project.

A company named CouchIO was founded to work on Apache CouchDB and later changed its name to CouchOne (I mean the company name, not the database name).

CouchOne (formerly CouchIO) merged with Membase (formerly NorthScale) to form a new company called Couchbase. Membase (the company) developed Membase (a product of the same name). Membase was created by several leaders of the Memcached project and used the Memcached protocol. After the merger of CouchOne and Membase, Couchbase continued developing the Membase software and later changed its name to Couchbase Server.

Today, I think most people believe that Couchbase Server is a new version of CouchDB, but in fact it is a new version of Membase. It still uses the Memcached protocol and does not use CouchDB's REST API. Meanwhile, CouchDB is still CouchDB, actively maintained and developed as an Apache project.

Now to the relevant differences:

Licensing

Couchbase Server is not entirely open-source/free software. There are two versions: Community Edition (free but without the latest bug fixes) and Enterprise Edition (there are restrictions on usage, confidentiality provisions, audits by Couchbase Inc. that «will be conducted during regular business hours at Licensee's facilities», and other terms typical of proprietary software that many people may find unacceptable).

CouchDB is open-source/free software (no strings attached), a project of The Apache Software Foundation, and is distributed under the Apache License, Version 2.0 (DFSG-compatible, FSF-approved, OSI-approved, GPL-compatible, non-copyleft, commercial-friendly).

Philosophy

I have never seen this pointed out directly, but it may actually be the biggest difference between these two databases because it is about the philosophy of distributed computing models and not just certain features, APIs, or licensing. CouchDB and Couchbase Server are completely different in their views on building distributed systems and databases.

According to the CAP theorem (consistency, availability, partition tolerance), it is impossible for a distributed database to simultaneously provide consistency, availability, and partition tolerance.

CouchDB is an AP-type system (provides availability and partition tolerance)

Couchbase Server is EITHER a CP-type system (according to Wikipedia) OR a CA-type system (according to the Couchbase technical update) — WHICH OF THESE IS CORRECT? PLEASE COMMENT.

Features

Here is what I considered worth pointing out from the list of CouchDB features that are not supported by Couchbase Server:

• no REST API (only for views, not for CRUD (create read update delete) operations);
• no _changes feed;
• no peer-to-peer replication;
• no CouchApps;
• no Futon (a different administration interface is available);
• no Document IDs (_design/ or _local/);
• no notion of databases (only buckets);
• no replication between a CouchDB database and Couchbase Server;
• no explicit attachments (you will have to store attached files as a new key/value pair);
• no HTTP API for everything (you need to use the Couchbase Server SDK or one of the experimental client libraries in Couchbase Develop, so no experiments with curl and wget);
• no CouchDB API (the Memcached API is used instead);
• you cannot do everything you want from the browser (you will have to write a server-side application);
• two-tier architecture for web applications is impossible (you will have to write a server-side application to sit between the browser and the database, as with relational databases);
• no eventual consistency;
• not entirely open-source/free software;
• not a full replacement for CouchDB (it looks more like a replacement for Memcached).

These CouchDB capabilities may or may not be important to you, so whether their absence is a disadvantage or not is strictly subjective. But I think the decision whether to switch from CouchDB to Couchbase Server should be based on these differences and on whether you depend on these capabilities in your current CouchDB-based implementation.

For example, if you became interested in CouchDB after watching the changes in CouchDB talk at NodeCamp by Mikeal Rodgers or one of the CouchApp tutorials by J. Chris Anderson, you should realize that if you want to switch to Couchbase Server, you will have to forget quite a lot of what they were talking about.

Because of that, I would say that Couchbase Server looks like an evolution of Memcached and Membase (not an evolution of CouchDB), and therefore looks like a good product if you are already using Memcached and Membase. If you use CouchDB only for the simplest tasks, you can consider using Couchbase Server for them and it may work better (if you do not care about the licensing restrictions). But if you use any features that are unique to CouchDB (for example, changes feed, CouchApps, two-tier architecture, peer-to-peer replication, and so on), then you should either forget about them or stay with CouchDB. In any case, make sure you read and understand the migration guide for CouchDB users to Couchbase before you think about switching.

People often get the wrong impression (perhaps after reading something like «What is the future of CouchDB? The future is Couchbase») that CouchDB is somehow obsolete compared to Couchbase Server, or that it is an old version of Couchbase. Meanwhile CouchDB is an actively developing open-source project, Couchbase Server is a completely separate project (it is a newer project, but it is not a new version of CouchDB — they are not even compatible), and since even new tools for creating CouchApps are still being developed (for example, the Kanso project), CouchDB is not going anywhere anytime soon.

I hope this helps clear things up. Please correct me if I am wrong anywhere.

Update:

Couchbase Server is actually the new name for Membase Server (it was renamed to Couchbase Server somewhere around version 1.8). Take a look at the Couchbase 2011 review:

Unfortunately, we confused the hell out of many of our users. In addition to Membase Server and our new mobile products, we also offered Couchbase Single Server, which was a packaged distribution of Apache CouchDB.

On top of that, we began releasing developer previews of Couchbase Server 2.0, which incorporated CouchDB technology into Membase Server — but this product was not compatible with Couchbase Single Server (or CouchDB). [...] Membase Server will be renamed to Couchbase Server 1.8 in its next January release — a small step to ease the confusion around the name. As planned from the very beginning, the Couchbase Server 2.0 release (currently Developer Preview 3) will add index and query functionality. While Couchbase Server 2.0 will include a substantial part of the technologies from the CouchDB project, it will not be backward compatible with CouchDB and should not be viewed as a «version of CouchDB».

aptitude install libcu-dev libcurl4-gnutls-dev libtool erlang-dev erlang libnspr4-dev g++ libmozjs185-dev libcu-dev libcurl4-gnutls-dev libtool libicu-dev
cd apache-couchdb
./configure --prefix=/opt/couchdb --sysconfdir=/etc/opt/couchdb

make
make install

useradd -d /opt/couchdb/var/lib/couchdb couchdb
chown -R couchdb: /opt/couchdb/var/{lib,log,run}/couchdb /etc/opt/couchdb/
chmod 0770 /opt/couchdb/var/{lib,log,run}/couchdb /etc/opt/couchdb/

ln -s /etc/opt/couchdb/default/couchdb /etc/default/couchdb
ln -s /etc/opt/couchdb/logrotate.d/couchdb /etc/logrotate.d/couchdb
ln -s /etc/opt/couchdb/init.d/couchdb /etc/init.d/couchdb

update-rc.d couchdb defaults
service couchdb start

After installation, it is better to reboot the server/computer, otherwise CouchDB starts by itself even if you stop it with service couchdb stop. After a reboot everything is fine.

I wrote this little script before New Year. It goes through all databases in CouchDB and builds all views one by one. Leaving it here.

<?php

            set_time_limit( 0 );

            // all dbs
            $ch = prepareCurlResource();
            curl_setopt( $ch, CURLOPT_URL, 'http://localhost:5984/_all_dbs' );
            $data = curl_exec( $ch );
            $dbs = json_decode( $data );

            foreach ( $dbs as $db ) {
                // skip _users and _replicator
                if ( substr( $db, 0, 1 ) == '_' )
                    continue;

                // getting all databases
                $chCC = prepareCurlResource();
                curl_setopt( $chCC, CURLOPT_URL, 'http://localhost:5984/' . $db . '/_all_docs?startkey="_design/"&endkey="_design0"&include_docs=true' );
                $data = json_decode( curl_exec( $chCC ) );

                if ( false === empty( $data->rows ) ) {
                    foreach( $data->rows as $design ) {

                        // creating views of design
                        if ( false === empty( $design->doc->views ) ) {
                            foreach( $design->doc->views as $viewName => $tmp ) {
                                echo 'Creating view: ' . $db . '/' . $design->id . '/_view/' . $viewName . "
";

                                $chCC = prepareCurlResource();
                                curl_setopt( $chCC, CURLOPT_URL, 'http://localhost:5984/' . $db . '/' . $design->id . '/_view/' . $viewName . '?limit=0' );
                                curl_exec( $chCC );
                            }
                        }
                    }
                }
            }

            function prepareCurlResource() {
            $ch = curl_init();
            curl_setopt( $ch, CURLOPT_PORT, 5984 );
            curl_setopt( $ch, CURLOPT_HEADER, false );
            curl_setopt( $ch, CURLOPT_RETURNTRANSFER, 1 );
            curl_setopt( $ch, CURLOPT_HTTPHEADER, array( 'Content-type: application/json' ) );

            return $ch;
            }
            

Today we upgraded CouchDB on the production server to 1.1.0. Ran into a problem — PUT requests didn’t work, returning a strange error:

[error] => unknown_error
[reason] => function_clause

I.e. we couldn’t update a single document in the database, while POST requests for creating new documents worked just fine.

It turned out that when upgrading CouchDB from an older version to 1.1.0 there are two versions of some module left in the system (it might affect several modules) — the old one and the new one. These two versions conflict with each other.

The fix was simple, although a bit weird. You need to find where the *.beam files are stored on the system (in our case it’s /opt/couchdb), delete them (if you’re nervous, you can move them aside), then go back to the CouchDB source folder and run again:

make install