3 ms·
> The actual row numbers are never exposed from the library API. Application logic should not need to know about them. This point confuses me. If we're thinkin
by mijoharas 2y ago
> The actual row numbers are never exposed from the library API. Application logic should not need to know about them.
This point confuses me. If we're thinking about a web server, you'll pass your data to the frontend with a row ID, so that they can refer to and modify that data in another request? How would it work otherwise?
Am I missing something? I can think of some use cases, but this limitation cuts down on the uses I'd have for this massively.
- twiss 2y agoI'm guessing they're talking about https://www.complexsql.com/rowid-rownum/ https://www.complexsql.com/rowid-rownum/, i.e. the row numbers defined by the database, rather than the value of the ID column you typically create in each table. I.e., it should still be possible to create a column with a public identifier by which you can refer to the row, I assume.
- Hytak 2y agoSending row IDs to your frontend has two potential problems: - Row IDs can be reused when the row is deleted. So when the frontend sends a message to the backend to modify that data, it might accidentally modify a different row that was created after the original was deleted. - You may be leaking the total number of rows (this allows detecting when new rows are created etc. which can be problematic). If you have nothing else to uniquely identify a row, then you can always create a random unique identifier and put a unique constraint on it.