Swap two rows in readable grid

You can us these code blocks in your

Down Arrow

a!save(
  ri!data,
  a!update(
    ri!data,
    {
      wherecontains(fv!row, ri!data),
      wherecontains(fv!row, ri!data) + 1
    },
    {
      ri!data[wherecontains(fv!row, ri!data) + 1],
      fv!row
    }
  )
)

Up Arrow

a!save(
  ri!data,
  a!update(
    ri!data,
    {
      wherecontains(fv!row, ri!data),
      wherecontains(fv!row, ri!data) - 1
    },
    {
      ri!data[wherecontains(fv!row, ri!data) - 1],
      fv!row
    }
  )
)

I believe instead of using this

wherecontains(fv!row, ri!data)

fv!identfier

Have been using it for ages. Did not find any issue :)

just for learning purpose, is it good to have 3 where contains per row in a grid where we can use fv!identfier? or it will break in any corner cases?

It will break. fv!identifier gives you the primary key. So if you are in the second page, fv!identifier will not start with 1. Hence fv!identifier <> fv!index

yes it will not start with 1 on second page it will continue assigning unique identifier to each row. So my theory here is - as we don't want the index of the item according to the current page but the index of the item according to the whole data right? so fv!identifer will provide the current index of the item according to the whole data, working in place of wherecontains in grid and this scenarios

yes it will not start with 1 on second page it will continue assigning unique identifier to each row. So my theory here is - as we don't want the index of the item according to the current page but the index of the item according to the whole data right? so fv!identifer will provide the current index of the item according to the whole data, working in place of wherecontains in grid and this scenarios

If you play with the identifier, you will need to make sure that everything in the DB also gets updated instantly to reflect on the screen. But this comes with its own challenge. What do you think will happen with the Primary keys? How will you change the order of these rows in the DB keeping the same primary keys?

I was wondering about the role of the primary key in this context. As far as I understand, fv!identifier seems to align its own sequence (1, 2, 3, 4, ...) in the grid. Please correct me if I'm mistaken. I appreciate your clarification on this matter.

Harshit Bumb (Appyzie) said:

If you play with the identifier, you will need to make sure that everything in the DB also gets updated instantly to reflect on the screen

i think this is an important factor that needs to be drilled down into WAY more with OP prior to recommending any particular approaches here, since we don't really know what their desired end-effect is for the data in question.

balti said:

As far as I understand, fv!identifier seems to align its own sequence (1, 2, 3, 4, ...) in the grid

GridField is designed to work in 2 ways. 

1. Get all the data in local variables and just show some of it in the grid. Here the paging happens on the interface level and fv!identifier's output becomes uncertain. (like you have done in the screenshot you attached)
2. Get only a page's data from the DB and let the grid automatically query the next page, directly from the DB. In this approach, you pass directly the entire data subset in the grid. Once the grid displays data using the data subset, it will give primary keys when fv!identifier is referenced. 

So it depends on case to case but because fv!identifier's behavior isn't 100% same every time you pass just the Data and NOT Subset, I prefer passing the entire fv!row in the whereContains. 

And anyway, using a read-only grid and rearranging the rows isn't a good option. Because this grid isn't made for that, even if somehow it supports that. 

I've just tested it, and it worked exactly as you explained. I wasn't aware that fv!identifier gives the primary key when we are querying only current page's data . Thanks a lot, Harshit Bumb (Appyzie) . I've learned something new.