couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joan Touzet <woh...@apache.org>
Subject Re: Confused Design Docs
Date Fri, 31 Mar 2017 10:45:58 GMT
Hi John, 

Haha, yes of course! Changing the _id is changing the "Primary Key" 
of the document, aka its "name." If you do that, remove entirely 
the _rev property and you should have no problems with Futon. It 
will give you back a 1-.... initial revision. 

Best, 
Joan 

----- Original Message -----

> From: "John Le Brasseur" <johnlebrasseur@gmail.com>
> To: user@couchdb.apache.org, "Joan Touzet" <wohali@apache.org>
> Sent: Friday, March 31, 2017 3:57:23 AM
> Subject: Re: Confused Design Docs

> Hi Joan.
> OK What I have been trying to do is 'update' the design doc name,
> which is its _id, which is seemingly 'non-updatable'.
> Is that correct, is any _id not 'updatable' under ANY circumstances.
> In other words in all cases a new doc is/must be created!
> CouchDB 101 lesson one, paragraph 1, sentence 1, fact 1.!!!!!!!
> One doesn't always think of that name as its _id but of course it is
> actually.!!!

> On 30 March 2017 at 20:05, Joan Touzet < wohali@apache.org > wrote:

> > John,
> 

> > This sounds possibly like a Futon bug...and Futon is no longer
> > being
> 
> > maintained. Did you reload the page before trying to edit the code?
> 
> > If not the page will have the old _rev data in it and your change
> 
> > will fail.
> 

> > Would you try the same thing from the command line using curl?
> > First,
> 
> > get a copy of your design document:
> 

> > curl http://your-server:5984/dbname/_design/viewdocname > viewdoc
> 

> > Then, edit the design document (being sure to remove any newlines,
> > or
> 
> > convert them to \n) using your favourite editor.
> 

> > Then, PUT it back to the database:
> 

> > curl --upload-file viewdocname \
> 
> > http://your-server:5984/dbname/_design/viewdocname
> 

> > You should get back an {"ok":true,..."} that includes the
> > document's
> 
> > new revision number.
> 

> > If this succeeds, you've likely hit a Futon bug, one that probably
> 
> > won't be fixed. Sorry about that.
> 

> > -Joan
> 

> > ----- Original Message -----
> 
> > > From: "John Le Brasseur" < johnlebrasseur@gmail.com >
> 
> > > To: user@couchdb.apache.org
> 
> > > Sent: Thursday, March 30, 2017 11:55:03 AM
> 
> > > Subject: Re: Confused Design Docs
> 
> > >
> 
> > > Thanks Jan.
> 
> > > (v 1.6.1): I am editing the code inside futon using the steps:
> > > view,
> 
> > > design
> 
> > > documents, selecting the specific design document in 'source' and
> 
> > > then
> 
> > > editing it right there.
> 
> > > When I try to save the changes, I get the error I indicated.
> 
> > > It's almost as if there is a conflict but no conflicts are shown
> > > when
> 
> > > searched for.
> 
> > > The design document shown should be the 'latest'. Hence my
> > > question.
> 
> > > It
> 
> > > should save no matter what changes are made.
> 
> > > It seems as if there is 'something' corrupted but everything
> > > looks
> 
> > > correct.
> 
> > >
> 
> > >
> 
> > >
> 
> > >
> 
> > >
> 
> > > On 30 March 2017 at 17:09, Jan Lehnardt < jan@apache.org > wrote:
> 
> > >
> 
> > > >
> 
> > > > > On 30 Mar 2017, at 15:20, John Le Brasseur
> 
> > > > > < johnlebrasseur@gmail.com >
> 
> > > > wrote:
> 
> > > > >
> 
> > > > > Is it possible that when editing design docs in v 1.6.1 and v
> 
> > > > > 2.0.0 and
> 
> > > > > then replicating both ways, that 'something' can go wrong?
> 
> > > >
> 
> > > > Not really, no.
> 
> > > >
> 
> > > > > I have found my design docs sent both ways become uneditable
> > > > > and
> 
> > > > > I had to
> 
> > > > > create entirely new design docs with very different names to
> 
> > > > > solve it.
> 
> > > > If I
> 
> > > > > tried editing them, the doc refuses to save and says: Error
> 
> > > > > conflict
> 
> > > > > Document update conflict.
> 
> > > >
> 
> > > > Sound like you’re not sending the correct _rev in your update.
> > > > It
> 
> > > > works
> 
> > > > like
> 
> > > > with all other documents.
> 
> > > >
> 
> > > > Best
> 
> > > > Jan
> 
> > > > --
> 
> > > >
> 
> > > >
> 
> > > > > John
> 
> > > >
> 
> > > >
> 
> > > John
> 
> > >
> 

> John
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message