[java] Add tips and tricks section

[vmikhailenko]

Opens a FAQ section with one nasty corner-case that we discovered internally. Just so we can later reference to it.

[BraunMatthias]

should this section rather focus on avoid expensive joins by providing the foreign key to associated entities instead of associated entity values (example with user name)? The name can be resolved when reading the logs on basis of the id.

[vmikhailenko]

We never documented the runtime manipulation of changelog.

I could add a little explainer. Something like: if you need custom identifier, write an handler...

[BraunMatthias]

I think the remote scenario is not valid - it's rather about how to deal with associated entities with best possible performance. User (as Remote) would be a nice example: the user.id FK can be resolved at READ time of the ChangeLog, but creation of logs would be much cheaper if no join is required to Users.

[renejeglinsky]

I'm trying to understand this example and what it does. Let me try and make it a bookshop example to show how I'd understand it right now:

User = User
Entity = Orders

So if I'm logged in and for some reason have the authorization to read all orders, I'd nevertheless only see my orders when reading the Orders entity due to this modelling (and custom code). Is that correct?

[vmikhailenko]

It is simpler: you have an entity that is somehow is expensive to join. E.g. it is external or federated. Should be typical for users or so we think.

You can avoid join by using PK as an identifier (or combination of keys when the entity has more than one) and later fill the value on read when needed.