1 Reply Latest reply on Nov 19, 2012 1:27 AM by Steve Gardner

    Updating two items at once - changes not saved

    Steve Gardner

      I'm writing a simple function to swap the order of two elements in a list, but getting inconsistent behaviour when using the function.
      Most of the time it works as expected, but if used regularly it will invariably fail to update one of the item's display indexes.


      The code I have in my controller is as follows (there is a similar move down function which also has this problem):


         def moveUp

          #Move this stop up one place in the list of stops.

          @movedStop =  Stop.find(:first, :conditions => {'StopID' => @params['StopID']})

          origIndex =  @movedStop.DisplayIndex.to_i

          @demotedStop = Stop.find(


            :conditions => { {:func=> 'CAST', :name=> 'DisplayIndex As INTEGER', :op => '=='} => (origIndex)})


           @demotedStop.DisplayIndex = origIndex

           @movedStop.DisplayIndex = (origIndex - 1)




          redirect :action => :index, :query => {'RouteID' => @movedStop.RouteID}



      On some occasions this works fine, but on others the demoted stops display index is not changed when the data is queried again.  Stepping through with a debugger, the values always get set correctly, but when they are next recalled it looks like the save hasn't worked correctly.


      I also tried using


      @demotedStop.update_attributes('DisplayIndex'=> origIndex)


      but this produced similar results.


      Does RHOM support multiple updates like this, or should I bepproaching the differently?



        • Re: Updating two items at once - changes not saved
          Steve Gardner

          I managed to solve this myself.
          The rhom stuff and the updates were all working correctly.  However I was inadvertanly syncing more than expected with my device, so I had multiple stops with the same display index in the stops model, some of which were not being displayed.
          The code was simply updating the first stop it found with the matching display index.  Sometimes that was the stop being displayed, other times it was a completely separate stop.

          Once I realised this I could add an extra clause to my query to ensure the right stop was selected, and also filter the data being sent to my device a little more effectively.