mORMot Open Source

lagodny

Member

Registered: 2015-01-28

Posts: 50

Customizable RecordReference

I suggest to add a constant than defines the RecordReference calculation rules (not specifying the number 64 in different parts of the code). And make it available for modification by the developer

const 
  REC_REF_MAX_TABLES: Word = 64;

function RecordReference(Model: TSQLModel; aTable: TSQLRecordClass; aID: TID): TRecordReference;
begin
  if aID=0 then
    result := 0 else begin
    result := Model.GetTableIndexExisting(aTable);
    if result>=REC_REF_MAX_TABLES then
      result := 0 else
      inc(result,aID * REC_REF_MAX_TABLES);
  end;
end;

Is it possible or am I missing something?

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,661

Website

Re: Customizable RecordReference

I don't think it is a good idea, because it is error prone as a global constant.
It may be safer as part of the TSQLModel.

If you need another bit mask, you could encode your own value and use it in your code.

lagodny

Member

Registered: 2015-01-28

Posts: 50

Re: Customizable RecordReference

I was thinking about the model. But there are functions that work without it. For example:

function RecordRef.ID: TID;
begin
  result := Value shr 6;  // 64=1 shl 6
end;

Maybe should modify them:

function RecordRef.ID(Model: TSQLModel): TID;

If you need another bit mask, you could encode your own value and use it in your code.

I didn't quite understand how it helps me, because I need all the power of the mORMot's  TRecordReference and TRecordReferenceToBeDeleted

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,661

Website

Re: Customizable RecordReference

You could use a field per referenced table. Size on disk would be minimal.

lagodny

Member

Registered: 2015-01-28

Posts: 50

Re: Customizable RecordReference

And yet I would rather use RecordReference.
In my opinion, this is a great solution - to store the table and ID in one field, which in fact has only one limitation - the number of tables. And it would be cool to be able to bypass this limitation. Of course, it would be even cooler to have its own function for forming RecordReference, perhaps some kind of virtual method of the model .. But this will require serious refactoring. Adding a constant or model property is much cheaper in terms of time.
Arnaud, this is very critical for me. I'm getting to the point where 64 tables are not enough.