Support multiple tables under one entity

[lavrukov]

We need a possibility to work with couple tables under one Entity.

The most convenient way for us - create table with something like tableName by Tx.Current.get().getRepositoryTransaction().table(entityCls, tableName)

In this case we have to think at least about:

• names in projections
• behavior in SchemaChecker

[nvamelichev]

Did you try dynamic entities (@Schema.Dynamic), they call the entity's NamingStrategy.getNameForClass() each time the table is used. I think Audit Trails in YC has used this feature once (you can ask them and search in git history; currently they don't use it.)

[lavrukov]

Did you try dynamic entities (@Schema.Dynamic), they call the entity's NamingStrategy.getNameForClass() each time the table is used. I think Audit Trails in YC has used this feature once (you can ask them and search in git history; currently they don't use it.)

Dynamic hard to use. I propose something like this #33

[estekhin]

Instead of plain table name, it would be better to pass the whole NamingStrategy to support renames for columns too.

[nvamelichev]

Supporting custom NamingStrategy would be more complex, we'll have to have same-entity table with essentially different Schemas (because column names would be different for different invocations of BaseDb.table(...)). Just supplying a custom table name would be much simpler, I think.

In addition, the NamingStrategy's setName(JavaField) method is just a bad bad influence. We plan to make JavaField.name immutable (eventually) but adding new NamingStrategy use cases and possibly new implementations - does not help that goal.

[estekhin]

We are using custom NamingStrategy for some entities which we do not control (can't change their annotations or fields), and right now we are registering that NamingStrategy via static SchemaRegistry.getDefault().namingOverrides().add(type, strategy).

The problem with that method is that it must be called before any other code that will query EntitySchema for that type, otherwise the schema registry will initialize the default naming strategy for that type.

Passing the NamingStrategy at the point where the table is being created feels like the cleanest way to remove or at least minimize the dependencies on the static state.

I don't get the point about "bad bad setName(JavaField)". There should be a way to override column names, and it could provide a better api than setName(JavaField).
setName(JavaField) is just the implementation detail, but we still need a feature to rename columns for entities which code is outside of our control.