overwritten _id

[flamingo-peacock]

trafficstars

I am getting data over written by a later call.

All calls are from the same function that lives on props in my react-native project. Every call happens in the same way. I am getting a successful return of data from all calls to add.

This is my function, which stores only if offline:

 logIfOnline(eventType, data) {
    if(this.state.isOnline) {
      console.log(eventType, data)
      // will eventually get sent to server
    }
    else {
     // save locally if offline, to later send to server
      console.log('event saved')
      var eventData = {
        eventType,
        data
      }
      DB.EventStore.add(eventData, (added_data) => {
        console.log(added_data)
      })
    }
  }

3 calls, from three different places in app-

this.props.logIfOnline('stopped', time)

this.props.logIfOnline('over written event', time)

this.props.logIfOnline('another event', time)

This is what my log looks like-

I/ReactNativeJS: event saved
I/ReactNativeJS: { eventType: 'stopped',
                   data: Fri Oct 21 2016 16:33:13 GMT-0600 (MDT),
                   _id: 72 }
I/ReactNativeJS: event saved
I/ReactNativeJS: { eventType: 'over written event',
                   data: Fri Oct 21 2016 16:33:15 GMT-0600 (MDT),
                   _id: 73 }
I/ReactNativeJS: event saved
I/ReactNativeJS: { eventType: 'another event',
                   data: Fri Oct 21 2016 16:33:17 GMT-0600 (MDT),
                   _id: 73 }

[kylegoetz]

By any chance do these calls happen in rapid succession? I've noticed if I do a data.map(datum => db.add(datum)) it each row that gets inserted will have the same _id. The only way I could get around it is to do something like

data.reduce((memo, datum) => memo.then(()=>new Promise(resolve=>db.add(datum, result=>resolve(result))) , Promise.resolve())

in order to force the insertions to be sequential

If you try data.forEach(datum => ...) instead, it will insert the rows in quasi-parallel, and I guess, although I haven't verified yet, the code in RNDM that increments the _id is at an inopportune place that doesn't get incremented in time for parallelized insertions.