The PK column in the history table is currently set to be an int with no straight forward method for providing an alternate type. In large scale systems this presents a hard cap on the number of history entries that can be created at a bit more than 2 billion. This is a large but not outrageously large value given that the table will log all changes written to the database. In addition most databases value uniqueness and speed over density when assigning int pk values so the actual number of records written can be significantly lower than ~2 billion. In practive in some of our high usage systems we are having to roll the audit table every couple of months.
We working on a work around that adds a value converter to the id property to "convert" the int ud to Guid.NewGuid(). This works to some degree but means we need to define a seperate model class to treat the audit log as a view if we want to retieve any data from it.
I think changing the type outright would probably present a major breaking problem for a number of applications but I think providing an option to inherit from a generic type would allow those that need it to define their own PK.
The PK column in the history table is currently set to be an int with no straight forward method for providing an alternate type. In large scale systems this presents a hard cap on the number of history entries that can be created at a bit more than 2 billion. This is a large but not outrageously large value given that the table will log all changes written to the database. In addition most databases value uniqueness and speed over density when assigning int pk values so the actual number of records written can be significantly lower than ~2 billion. In practive in some of our high usage systems we are having to roll the audit table every couple of months.
We working on a work around that adds a value converter to the id property to "convert" the int ud to Guid.NewGuid(). This works to some degree but means we need to define a seperate model class to treat the audit log as a view if we want to retieve any data from it.
I think changing the type outright would probably present a major breaking problem for a number of applications but I think providing an option to inherit from a generic type would allow those that need it to define their own PK.