Hi all,
+1 to skip the 0.10 release.
Thanks,
Alex
On Sat, Jun 7, 2025 at 2:52 AM Dmitri Bourlatchkov wrote:
>
> Skipping the 0.10.0 release and going for 1.0.0 sounds good to me.
>
> Cheers,
> Dmitri.
>
> On Fri, Jun 6, 2025 at 6:49 PM Jean-Baptiste Onofré wrote:
>
> > Hi everyone,
> >
> > As
Sounds good to me.
Yufei
On Tue, Jun 10, 2025 at 3:53 PM yun zou wrote:
> Hi Team,
>
> Thanks a lot for all the valuable feedback!
>
> I want to bump this thread up and see if we can conclude on the direction
> to move on.
>
> For the V1 generic table spec, we would like to start with support o
After this latest round of changes, it looks good to me too! Thanks for
working on this.
On Tue, Jun 10, 2025 at 4:56 PM Yufei Gu wrote:
> Sounds good to me.
> Yufei
>
>
> On Tue, Jun 10, 2025 at 3:53 PM yun zou
> wrote:
>
> > Hi Team,
> >
> > Thanks a lot for all the valuable feedback!
> >
> >
Hi Team,
Thanks a lot for all the valuable feedback!
I want to bump this thread up and see if we can conclude on the direction
to move on.
For the V1 generic table spec, we would like to start with support of
single location, and leave multiple location
support as an open discussion which could
Hi Laurent,
Thanks a lot for the reference. Yes, you are right, the current generic
table support is very
general, there is no specific field to describe metadata information,
schema etc. Most of the
interpretation responsibility is on the Client, for example, we have
shipped a Polaris Spark Clien
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, 2025 at 5:59 PM Laurent Goujon
wrote:
> I appreciate the sizable amount of effort being put here but isn't the
> generic table proposal as
Yes, you're right and yes I am. The thing is that even with the storage
location, it is not enough for clients to decide on the behavior to use to
interpret the data. How types are being mapped, which files are being
considered (no extension, specific extension, compression support), what
would be
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
Hi Dmitri, hi all,
> move the `@MeterTag(key="realm_id",expression="realmIdentifier")` annotation
> to the method level.
I tried that as well, and even if it's possible to place the
annotation at method level, it seems that doing so is not supported:
the expression resolver doesn't get invoked a
