No. Everything is fine, I'm really happy I can annotate _id and _rev and leave the other fields as set or null since couchdb will automatically add the _id and _rev fields on POST. I'm just amazed at how simple and elegant my persistence layer is compared to that when I use an RDBMS, I really do love couchdb!
All good! Thanks for the tip. Regards John On 9 October 2010 16:54, Heiko Schaefer <[email protected]> wrote: > i wonder if i understand you well ... sometimes you want to explicitly > store "null" as a value in couchdb (as opposed to not storing the entire > key in the first place)? > > > On 10/09/2010 05:39 PM, John Logsdon wrote: > > Many thanks Heiko - That works on a method level so doesn't affect the > > properties in my objects that need null as a value (Yes, the irony hasn't > > escaped me.......). > > > > I love couchdb. > > > > > > > > On 9 October 2010 15:57, Heiko Schaefer <[email protected]> wrote: > > > >> Hey John, > >> > >> maybe the jackson annotation @JsonWriteNullProperties(false) could help > >> you? > >> > >> cheers, > >> Heiko > >> > >> > >> On 10/09/2010 04:24 PM, John Logsdon wrote: > >>> I understand the difference but i'm not sure it's really an issue. > >>> > >>> My request is born out of convenience as i'm using a statically typed > >>> language (Java), a json parser(jackson) with auto marshalling and I'm > >> trying > >>> to use the same java beans regardless of whether it's a new Object or > >>> existing since I have rather a lot of classes to store in couchdb. > >>> > >>> It may be possible to fix this in the client but I thought it was worth > >>> asking! > >>> > >>> John > >>> > >>> > >>> On 8 October 2010 23:50, Paul Davis <[email protected]> > wrote: > >>> > >>>> On Fri, Oct 8, 2010 at 6:43 PM, John Logsdon < > [email protected] > >>>> wrote: > >>>>> Hi > >>>>> > >>>>> I'd like to be able to support the following scenario: > >>>>> > >>>>> curl -XPOST -H"Content-Type: application/json" > >> http://localhost:5984/uta-d > >>>>> '{"_id": null, "_rev":null,"x":"y"}' > >>>>> > >>>>> Which returns: > >>>>> > >>>>> {"error":"bad_request","reason":"Document id must be a string"} > >>>>> > >>>>> I'd like the above to work the same as this command: > >>>>> > >>>>> curl -XPOST -H"Content-Type: application/json" > >> http://localhost:5984/uta-d > >>>>> '{"x":"y"}' > >>>>> > >>>>> which returns: > >>>>> > >>>>> > >> > {"ok":true,"id":"c9fd97f3eb58fdb62ef7a80440001662","rev":"1-935564bc7ec7e86aa82ecec3face18f6"} > >>>>> Is there a reason why couchdb doesn't do the same action on a null > >>>> _id/_rev > >>>>> as it does when the fields aren't present? > >>>>> > >>>>> Regards > >>>>> > >>>>> John > >>>>> > >>>> A value of null is not equivalent to no value. Null is a value and its > >>>> not a valid document id. Hence, the error. > >>>> > >>>> I don't like the idea of silently discarding it and creating a new > >>>> document with a random doc id. I can see this causing lots of > >>>> headaches when someone has a bug and doesn't realize their code is > >>>> just creating random documents. > >>>> > >>>> Paul Davis > >>>> > >>> > >> > > > > -- John Logsdon CEO NetDev Limited +44 1273 773661 +44 7899 811245 http://www.netdev.co.uk Registered in England and Wales Company Number 04741258
