On Fri, May 9, 2014 at 4:25 AM, Mike Rhodes
 This is a secure message chain, protected by Virtru.
 wrote:

> In Classes/common/CDTDatastore+Conflicts.m:
>
> > +
> > +        //
> > +        //create a new TD_Revision to insert into the database
> > +        //
> > +        toPutRevision = [[TD_Revision alloc] initWithDocID:docId
> > +                                                     revID:nil
> > +                                                   deleted:[resolvedRev deleted]];
> > +        if(![resolvedRev deleted])
> > +            toPutRevision.body = resolvedRev.td_rev.body;
> > +
> > +        //and the new winner...
> > +        [strongSelf.database putRevision:toPutRevision
> > +                          prevRevisionID:currentWinningTDRev.revID
> > +                           allowConflict:NO
> > +                                  status:&status
> > +                                database:db];
>
> So, I've added the CDT* stuff when the resolved revisions is not deleted.
> But I haven't added any tests for the support attachments. And I want to
> point out of couple of things that I noticed. First, the CDTDatastore
> -updateDocumenWithId converts the TDStatus to an NSError using the
> TDStatusToNSError. The error code changes in this process to be equal to a
> CouchDB HTTP error, which has less information than a TDStatus error. In
> addition to setting *error, should we be logging this somehow (NSLog or use
> the TD* Log macro)?
>


> Where are you suggesting we log?
>

Well, I don't really know. In a previous comment regarding the construction
of the CDTPush/PullReplication objects, you mentioned that we could create
an init method that returns nil when the URL fails and then also produces
some log information. What did you mean by that? Just to the console? Is
there a stdout/stderr output that is normally used by developers for
debugging?


> Second, while tracking down the error codes, I noticed line 393 of
> TD_Database+Insertion.m. It seems that this method could return nil and not
> set the outStatus value. I think it should be set to kTDStatusDBError in
> this case. What do you think?
>


> Indeed, I can't see how `outStatus` is set. `kTDStatusDBError` looks like
> the right status code. Side note, please link rather than specifying line
> numbers, as it's quite possible line 393 could've been very different in my
> checkout/branch :)
>

I'll add a fix commit to this PR then.

> —
> Reply to this email directly or view it on GitHub<https://github.com/cloudant/CDTDatastore/pull/22/files#r12471725>
> .
>