Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A2C12DB0F for ; Wed, 7 Nov 2012 11:54:50 +0000 (UTC) Received: (qmail 25295 invoked by uid 500); 7 Nov 2012 11:54:49 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 25063 invoked by uid 500); 7 Nov 2012 11:54:48 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 25027 invoked by uid 99); 7 Nov 2012 11:54:47 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Nov 2012 11:54:47 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.214.52 as permitted sender) Received: from [209.85.214.52] (HELO mail-bk0-f52.google.com) (209.85.214.52) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Nov 2012 11:54:38 +0000 Received: by mail-bk0-f52.google.com with SMTP id j10so641919bkw.11 for ; Wed, 07 Nov 2012 03:54:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=EsMrdgfpQYY4Mj+bNCZ2Lwq3eQYa+0qi48Cj6XXG4cQ=; b=wcPz8mUdnP23atjLTekzBRDFYgGHrQsVgWTPRqui4GGGChaF2ILljLLeymGg3b+5WO DQzEDGSwbPAsjmHxHFWFqfHiQHHpyXnijavpM8H5vXXxl134aQGTiFee53pAuGicD/y+ Amx7n6Th6/yuaVd9fCHBm2gZM9Oz4vbbOrw+v6wHEk2yOdQzj9eiXlTO3sZIbuog0O3O ZaOyvGpfhGrLxpgMtfSLq6RzgN2Ok2xF40Y7OSG1/hAOat+hqk2xx7opPQedmDor/IMo t1bBIoMXgaKcXC7o/uU9MCJTYj4odmikiAK5OAR+IQ6Ijv5NKPsdexw58b16wE4G6/hX vlYQ== Received: by 10.205.118.136 with SMTP id fq8mr1017176bkc.24.1352289257822; Wed, 07 Nov 2012 03:54:17 -0800 (PST) Received: from [172.16.0.203] ([62.159.107.164]) by mx.google.com with ESMTPS id gy18sm14159863bkc.4.2012.11.07.03.54.15 (version=SSLv3 cipher=OTHER); Wed, 07 Nov 2012 03:54:16 -0800 (PST) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <250244C3-3880-4D07-98DD-7325AE89DFFF@gmail.com> Cc: "user@couchdb.apache.org" X-Mailer: iPhone Mail (10A403) From: Paul J Davis Subject: Re: Remote view looks different to localhost Date: Wed, 7 Nov 2012 12:54:11 +0100 To: "user@couchdb.apache.org" X-Virus-Checked: Checked by ClamAV on apache.org Double check that you're not hitting two different machines.=20 On Nov 7, 2012, at 12:46 PM, Stoo Goff wrote: > Hi, >=20 > I'm getting some strange differences when I view a database, depending on > whether I view the database remotely or locally. >=20 > The server: >=20 > Debian squeeze running Couchdb 0.11.0 >=20 > The dev box: >=20 > Ubuntu 11.10 running Couchdb 1.0.1 >=20 > I initially created the database on the dev machine, then replicated it to= > an empty database on the server. I have a web app running on the server > connecting over localhost and everything seemed to be working fine - in > fact as far as the web app is concerned it's all running perfect. >=20 > I changed the Couchdb settings so I could view the data remotely. > Initially, I used Futon to take a look and that showed me a completely > different set of data. So I tried looking at the data using CURL. That > showed me the same as Futon. >=20 > CURL run on the server: >=20 > curl -X GET http://localhost:5984/muninn >=20 > {"db_name":"muninn","doc_count":25,"doc_del_count":33,"update_seq":1194,"p= urge_seq":0,"compact_running":false,"disk_size":16826462,"instance_start_tim= e":"1351793407368363","disk_format_version":5} >=20 > CURL run on the dev machine: >=20 > curl -X GET http://user:pass@odin:5984/muninn >=20 > {"db_name":"muninn","doc_count":9,"doc_del_count":34,"update_seq":102,"pur= ge_seq":0,"compact_running":false,"disk_size":16826462,"instance_start_time"= :"1352219217053672","disk_format_version":5} >=20 > So, same disk size with completely different doc counts. With the remote > connection it looks like an historical view of the data, but why would it > do it? >=20 > Any help or insight would be appreciated! >=20 > Stoo