devonfw-forge / composited-keys-poc Goto Github PK

Hi @trivesc

thanks for your contribution to make devon4j better. I appreciate this a lot and will try to support you.

Do you have customer demands that define requirements on the technical data model and force you to do so? (do not tell details and customer names here in OSS space)

This is adding quite some complexity that can be avoided by having a technical primary key and maintaining the business key as additional attributes instead.
However, in some cases I can see your need and am willing to extend devonfw with your feature. But if we know your use-case and demands more detailed, we can better design and plan changes.

public class NameEntity extends ApplicationPersistenceEntity<Long> implements Name<Long>

I do not understand why NameEntity is already bound to Long while the entity interface Name still carries the generic type. IMHO this does not make sense and as generics are sometimes nasty for developers (esp. beginners) we should avoid them where possible. So IMHO it should be just Name here and that interface can then have the in its extends declaration.

Further we need to think about compatibility. ApplicationPersistenceEntity already exists in hunders of devonfw projects. Chaning this and the cobigen templates in an incompatible way is IMHO a very bad idea. Instead you can introduce a new super type ApplicationGenericPersistenceEntity<ID> and existing projects can modify ApplicationPersistenceEntity to extends ApplicationGenericPersistenceEntity<Long> and their code will still work and they can continue to use CobiGen with the same templates.
Do you agree and keeping compatibility for existing projects even if it leads to somewhat more artifical names?