Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
REVIEW: what's the best way to set the RowId?
See original GitHub issueWhen the entity is Modified or Deleted, we can set the RowId to the primary key, when the entity is Added, however, we should have a way to set the PrimaryKey to RowId.
more details, see DbContextExtensions
Issue Analytics
- State:
- Created 7 years ago
- Comments:14 (9 by maintainers)
Top Results From Across the Web
Is it safe to use ROWID to locate a row? - Ask TOM
A rowid is assigned to a row upon insert and is imutable (never changing) unless the row is deleted and re-inserted (meaning it...
Read more >Dealing with ROWIDs When Migrating to MariaDB
Another way of dealing with a generated ROWID is to reuse the primary key as it stands as a ROWID by using MariaDB...
Read more >ROWID (oracle) - any use for it?
ROWID is the physical location of a row. Consequently it is the fastest way of locating a row, faster even than a primary...
Read more >Using a RowID to identify a record - Progress Documentation
Every record in every table of a database has a unique row identifier. Note: The row identifier is only unique within a single...
Read more >Start Row ID part way through a new SS
The "Auto-Number" option allows you to set the starting number. You could give yourself a buffer and start auto-numbering from a unique first ......
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
What is the purpose of AutoHistory? If to keep a track of all DB transactions -except reading- then
ADDcould be implemented.But the newly inserted data is already in its own table , therefore there’s no need to keep a duplicate data of it. Data auditing should include past actions, because the current data is already in the correct place: its own table, own row.
Besides, AutoHistory table will be a sum of all the database, including past versions of data. It’s like an Excel worksheet with no removal support so that the update and delete actions are all in the same table. It’s unusable.
By supporting add, which is already meaningless, the application should do two round trips for the same action: A data inserted in a table.
That’s why I believe
ADDshould not be supported and the issue should be closed.@feldrim AutoHistory not want to keep a track of all DB changing. The usage is only for recording some important changes.
I agree now.