Thanks for the shoutout although I believe my contribution has been quite
modest as consisting mostly of providing some initial feedback, and I don't
think I had a key part in the overall design.
But I'm also excited by the recent interest surrounding FGAC with Robert's
proposal[1] and this proposa
Same comment as in the other thread regarding location and generic table:
how are clients supposed to interact with this format? Could we have a
detailed discussion about the protocol between the catalog and the query
engine?
Laurent
On Fri, Jun 13, 2025, 17:01 Vinoth Chandar wrote:
> +1
>
> I
ility concerns.
> > > > > >
> > > > > > Regardless of how deep current spec is in Polaris, I believe it
> is
> > > > > > important to have it written down as an artifact in the Polaris
> > > repo. I
> > > > > > know we had
ded to discuss the
> evolving the current Spec one step forward
> to standardize one of the critical information for cross engine sharing,
> and eventually help the support for credential
> vending.
>
>
> Best Regards,
> Yun
>
>
> On Wed, Jun 11, 2025 at 8:15 AM Lau
What I was trying to say is that i'm sure there's plenty of value for
spark, but in it's current state the value is little from a Polaris point
of view as an open catalog service?
Of course we can follow-up on that but is the current spec still considered
wip or when 1.0 will be released, we would
engines/clients implementation to reproduce the same behavior.
On Tue, Jun 10, 2025 at 6:49 PM Eric Maynard
wrote:
> To be clear, this thread is about adding a field to the already-existing
> type. It sounds like you’re advocating for adding even more fields?
>
> On Tue, Jun 10, 202
I appreciate the sizable amount of effort being put here but isn't the
generic table proposal as is it today too generic? Without some description
of the available types, without some metadata information (like the
schema), without some protocol on how a client should actually interpret
the content
Maybe I'm missing something, but aren't the engines the ones actually
interpreting/executing the views, not Polaris?
On Mon, May 19, 2025 at 10:27 AM Prashant Singh
wrote:
> Hi everyone,
>
> I’d like to propose adding *context-aware functions* to Apache Polaris so
> that view definitions can res
>
> Next, and since you mentioned Quarkus: when using Quarkus, the application
> state is entirely constructed at build time, not at runtime. It's thus not
> possible to just "drop a jar" somewhere with your listener implementation,
> and expect it to be picked up by the running Polaris server. Ins
Can you allow commenting on the doc? unless feedback should be provided via
the mailing list?
On Thu, Dec 5, 2024 at 3:21 PM Yufei Gu wrote:
> Hi Folks,
>
> Polaris has become a cornerstone for managing structured data across
> diverse processing engines, ensuring high performance and reliabilit
Wouldn't that cause issues with maven repositories when trying to upload
the artifacts (possibly miscategorized as release artifacts instead of
snapshots)?
On Thu, Nov 21, 2024 at 11:06 AM Dmitri Bourlatchkov
wrote:
> Hi All,
>
> This may be nitpicky but the current version in local builds is
>
Now I realize it wasn't mentioned if it is a SPI (something to extend the
codebase with) or a REST API (webhook). A public REST API for notifications
is cause of concern for me as it introduces some new complexity to deal
with availability issues.
So what type of APIs are we talking about?
Lauren
The first layer API/SPI seems like a no-brainer, the second layer seems
more convoluted and not as general purpose as the first layer. It also
seems that people could actually build their own history database tailored
to their use-cases using the first layer to populate the database.
Laurent
On T
13 matches
Mail list logo
