Decouple TEntityData mapping information from RTTI

[Sergey Burov]

It would be good to add opportunity of change Schema name in Entity in RunTime Thanks

[Stefan Glienke]

And why would that be? Or better: why would schema name help? What about table name? Column mapping?

So we might rather add a way to decouple the mapping information from the entity and make that exchangeable.

[Sergey Burov]

for our situation with postgres, we save some archive data in to other schema of database with same metadata

for example we have table

[Entity]
[Table('table_name', 'schemaname')]

and we have same table in archive schema name

[Entity]
[Table('table_name', 'schemanamearchive_date')]

also diffirent schema name with identical metadata can use for Restriction of rights or for partitioning data if database dont support this native

[Cesar Romero]

I also needed to change attribute values at runtime, and it is easy to achieve.

For this specific case, the properties in TableAttribute should be writable.

Like this:

in Spring.Persistence.Mapping.Attributes

TableAttribute = class(TORMAttribute)
   [...]
    property Schema: string read FSchema write FSchema;
  end;

then, get the attribute and set the new value

var
  Table: TableAttribute;
  OldSchemaName: string;
  NewSchemaName: string;
begin
  Table := TType.GetAttribute<TableAttribute>(TDatabaseConfig);
  OldSchemaName := Table.Schema;
  Table.Schema := 'changed_schema_name';

  NewSchemaName := TType.GetAttribute<TableAttribute>(TDatabaseConfig).Schema;
  TMessageBox.Show('OldSchemaName=%s, NewSchemaName=%s', [OldSchemaName, NewSchemaName]);
end;

---

OldSchemaName=, NewSchemaName=changed_schema_name

The code is using my own class helpers, but it is just to show how easy it is.

[Stefan Glienke]

We won't do it that way.

Attributes are part of the RTTI and the RTTI controls its lifetime. So we rather improve the metadata layer (TEntityData) that will get initialized via attributes by default but could also be initialized from other sources (I know people asked for file based configuration that makes it possible to map to different database/schema/... without recompilation or code change)

[Cesar Romero]

For sure loading metadata from other sources is the way to go.

My code is just to do some runtime changes by myself, and maybe help Sergey to do the hack while Spring do not supports it properly.

[Stefan Glienke]

I just wanted to give you heads up to be aware that any hack might not work/compile anymore in the future.

[Inkvizi]

"So we rather improve the metadata layer (TEntityData) that will get initialized via attributes by default but could also be initialized from other sources" Will these changes affect performance?

[Stefan Glienke]

TEntityData already exists. It just keeps references to the attributes being loaded by the RTTI rather than take the relevant properties.

Any change there is irrelevant to performance. Performance in an ORM comes from other areas like caching SQL statements to not generate them over and over all the time (which we currently do btw). This could also be kept inside of the TEntityData instances in the future.

[Inkvizi]

In my question, I was interested in the moment with reading the schema changes from the file. Is it will be reading file on each request or re-initialized only by some event of config changing?

[Stefan Glienke]

"reading file on each request"

That would be really stupid - don't you think?

As you can see for yourself currently the moment a TEntityData instance is created it reads the RTTI one time and just reads from the kept attribute instances after that (knowing that the rtticontext keeps them alive). Most likely the TEntityData itself will not read anything anymore but something else fills it with the information taken from RTTI, file or whatever.

I will however not implement any change notification. If you feel the information that was provided at construction time of TEntityData is not correct anymore or you want it to be changed then you can do that either by fiddling with its properties or reload the information from the data provider again.

So far for the concept

[Inkvizi]

Ok. So TEntityData and TEntittyCache is a internal kitchen of ORM and I hope that for cunsomer TEntityData information update will be brought to a higher level. In TSession for example or somewhere else. And it will be nice if it will be possible to update both all and each individual.

[Stefan Glienke]

As already announced further development regarding new features and fixing non trivial bugs or design issues of the ORM will be put on hold.