entitySelections/entity attribute exposure

i have a datatable. the selected row of the datatable is called selected. the datasource is an entitySelection. if the PK of said dataclass is numeric/autoincrement, (not exposed, to keep the datastore from being so easily tampered with). how does qodly identify the entity when it sends information about it back to the server?
in that other tool, i used to use uuid’s for PK’s, but changed back to the good old days, because it was much easier on server to chase issues with numbers than it was with uuid’s.
for our public-facing apps, we then limited access to function calls, and sent uuid’s in lieu of id’s to keep folks from mining the data (each entity had a uuid field).

Hello Mikey!

If you’re facing issues with security and want to hide your primary key from the final users, you can try creating another field that’s unique too, and not expose it while keeping your PK exposed.

By default, even if you try unexposing the PK and work, another unique identifier besides the PK is created and is the one used to identify that latter.

Hello Fadwa!
i don’t think the second paragraph. are you saying that qodly auto-generates an attribute, automagically, if i don’t expose the pk? is there a way to access this attribute? i have, in one of the forms i designed, a collection, instead of an entity selection, for populating a data table. if i create a uuid attribute for the table, i can pass that back to the server for some operation, but if qc is generating an attribute, automatically, and i could access it, i wouldn’t need to create the uuid attribute, and populate it, at all.

Hello again!

Actually, you can access and view the value of this key attribute using the rest api, but you can’t get its value and manipulate it in qodly studio.

i know that __KEY is part of the entity, but i thought that it was always the same value as the pk. so, if the pk isn’t exposed, is the same value going to show up in __KEY, anyway?
is the only way to make __KEY a uuid (and therefore harder to abuse) to make the pk a uuid?

Exactly, but If you’re concerned about security and want to make it harder to guess the keys, using UUIDs as primary keys will be a good choice.

interesting. the consensus on that other forum was to stick to numeric/autoindexed pk’s and add a uuid search field (but, obviously that other tool is going to behave the same way qc does)