You are not logged in.
Or am I doing something wrong ;-)
In the constructor code TSQLRestServer.Create(aModel: TSQLModel; aHandleUserAuthentication: boolean)
In the mORMot module on line 38,271 there is this code:
if fTrackChangesHistoryTableIndexCount>64 then
fTrackChangesHistoryTableIndexCount := 64; // rows are identified as RecordRef
I don't understand why this kind of code and how it relates to the comment next to this code, but it has further implications.
I have registered a table in a model that has an index in DataModel = 173.
I associated my tables with change tracking and noticed that it sometimes works and sometimes not.
During debugging it turned out that in the method TSQLRestServer.InternalUpdateEvent in line 42790 there is such a code:
if cardinal(aTableIndex)<fTrackChangesHistoryTableIndexCount then begin
TableHistoryIndex := fTrackChangesHistoryTableIndex[aTableIndex];
if TableHistoryIndex>=0 then
DoTrackChanges(TableHistoryIndex);
end;
In my case, this condition is not met because there is a hard-coded limit to the variable fTrackChangesHistoryTableIndexCount = 64.
So the DoTrackChanges method will only be called for tables that have been registered in the DataModel with an index less than 64.
My table has index=173...
When I commented out this limit in the TSQLRestServer.Create constructor then everything seems to work normally.
AB, could you shed more light on this case?
Offline
As the comment states, the data use a RecordRef to store the reference.
So there is a limitation to 64 tables.
If you overrange it, it is at your own risk. It is not tested on our side.
Offline
As the comment states, the data use a RecordRef to store the reference.
So there is a limitation to 64 tables.
Hmmm... Just so we understand each other correctly, you are referring to the table count limitation for the TSQLRecord class and not TSQLRecordHistory?
If you overrange it, it is at your own risk. It is not tested on our side.
OK, I understand.
When I remove this limitation, in what cases can this mechanism cause problems?
If I want to have change history tracking for more than 64 tables then how can I solve it differently?
I'll just add that I'm not keeping it all in one History table, but in several.
Also, I used what you wrote AB in the documentation: 7.3.6 Redirect to an external TSQLRest
And I delegated the history to a separate instance of TSQLRestServerDB which works with a SQLite database.
Perhaps the target will be more instances and other beeps, we'll see; my data model is large and complex...
I also have a lot of data changes (much, much more than a classic ERP system), but I MUST keep track of change history for all data.
Offline
OK, I looked in CreateHistory and understand more how it works.
And I already know that this breaking of fTrackChangesHistoryTableIndexCount leads to problems.
Thanks AB for the explanation.
Offline