As mentioned on the PR, I'm in favor of having concern-oriented APIs
that provide use-case oriented functionality without exposing and
force-pushing persistence implementation details upwards.
The proposed approach requires call sites to deal with the parent-child
and ID-based data modeling sp
Thanks for chiming in. Agreed with JB that we don't need typeCode or
PolarisBaseEntity, we may still keep a root class/interface for Polaris
entities without any fields. So it's more flexible than PolarisBaseEntity.
This is the next step of the effort though. Agreed with Eric, that we
should couple
Hi Yufei
Thanks for bringing this!
I have a few comments:
1. I agree with the challenges you mentioned ... but I would push
further :) Imho, I don't see a huge value to have PolarisBaseEntity,
including for clarity on the use and code. I would rather prefer that
each entity is atomic (not inherit
