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

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.

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.