That sounds great. It seems like a hard task to get right, but it’s
definitely the right thing to do.
Mike
On Fri, Dec 6, 2024 at 10:47 AM Dmitri Bourlatchkov
wrote:
> Very good point about business logic in PolarisMetaStoreManagerImpl.
>
> I'd also add that the Resolve also mixes different con
Very good point about business logic in PolarisMetaStoreManagerImpl.
I'd also add that the Resolve also mixes different concerns, specifically,
it appears to perform cache invalidation / synchronization as part of
object "resolution" phase, which also complicates reasoning about what
services expe
My intention when splitting up the PolarisMetaStoreManager interface was
always to cut the ties between the persistence manager and the other
responsibilities. For me, the first step seemed to break up the interface,
then change the consumers to depend on the most specific interface needed
to accom
I think this is a great idea. Even if we put aside the NoSQL / RDBMS point,
simply clarifying the roles & responsibilities of the persistence
interface(s) would be a welcome improvement.
--EM
On Tue, Dec 3, 2024 at 5:57 AM Dmitri Bourlatchkov
wrote:
> Hi All,
>
> I believe it was already discus
Hi All,
I believe it was already discussed elsewhere that it is valuable to allow
Apache Polaris to be extensible, and in particular extensible in how it
interacts with its own Persistence backend (not to be confused with Iceberg
data storage).
I’d like to formalize the expectations Polaris Core
