+1 (binding)
assuming we explicitly state RFC-8259
On Tue, Apr 30, 2024, at 08:02, Matt Topol wrote:
> +1 (binding)
>
> On Mon, Apr 29, 2024 at 5:36 PM Ian Cook wrote:
>
>> +1 (non-binding)
>>
>> I added a comment in the PR suggesting that we explicitly refer to RFC-8259
>> in CanonicalExtension
+1 (binding) pending agreement on the endianness which I agree needs to be
specified in the docs. While I lean towards big-endian as it appears most
implementations of UUID use a big-endian byte order, I don't much mind what
endianness we use as long as we explicitly specify it in the spec.
On Mon
+1 (binding)
On Mon, Apr 29, 2024 at 5:36 PM Ian Cook wrote:
> +1 (non-binding)
>
> I added a comment in the PR suggesting that we explicitly refer to RFC-8259
> in CanonicalExtensions.rst.
>
> On Mon, Apr 29, 2024 at 1:21 PM Micah Kornfield
> wrote:
>
> > +1, I added a comment to the PR becaus
+1 (non-binding)
I added a comment in the PR suggesting that we explicitly refer to RFC-8259
in CanonicalExtensions.rst.
On Mon, Apr 29, 2024 at 1:21 PM Micah Kornfield
wrote:
> +1, I added a comment to the PR because I think we should recommend
> implementations specifically reject parsing Bin
+1 (non-binding)
First of all, thanks Rok for working on this 🙌 I raised the mentioned
issue on GitHub back in December 2022 and I still believe it would be a
good addition to the spec.
In Iceberg UUIDs are encoded using big endian. For example, the UUID:
f79c3e09-677c-4bbd-a479-3f349cb785e7 is e
You are correct, it looks like UUID version should be encoded properly in
the UUID data, I think another concern around endianess was raised which
should probably be resolved before the vote is finalized.
Thanks,
Micah
On Monday, April 29, 2024, Felipe Oliveira Carvalho
wrote:
> Isn't that easi
Isn't that easily decodable from the UUID data itself?
If you allow the version to be specified as metadata, you now have to
validate and make sure it's consistent with the version encoded in the
contents of the UUID column. And UUID versions are more of a concern
for UUID generation than consumpt
Apologies for the late reply, but I think being able to specify the UUID
version as metadata might make sense in some cases?
On Fri, Apr 19, 2024 at 1:22 PM Rok Mihevc wrote:
> Hi all,
>
> Following initial requests [1][2] and recent tangential ML discussion [3] I
> would like to propose a vote
+1, I added a comment to the PR because I think we should recommend
implementations specifically reject parsing Binary arrays with the
annotation in-case we want to support non-UTF8 encodings in the future
(even thought IIRC these aren't really JSON spec compliant).
On Fri, Apr 19, 2024 at 1:24 PM
Thanks Raúl ! It makes sense in terms of timing.
Regards
JB
On Wed, Apr 24, 2024 at 3:41 PM Raúl Cumplido wrote:
>
> Due to unexpected issues (my computer died) I'll move the feature freeze to
> early next week.
>
> Thanks
> Raúl
>
>
> El jue, 18 abr 2024, 17:01, Raúl Cumplido escribió:
>
> > H
Hi
I think it's time to drop JDK8 support. I would say that we should
keep Java11 (jumping directly to Java17 would be problematic
potentially for some users I guess).
Regards
JB
On Thu, Apr 25, 2024 at 10:21 PM James Duong
wrote:
>
> If we dropped JDK 8, we could use the JDK to compile module-
The Apache Arrow community is pleased to announce the 16.0.0 release.
It includes 385 resolved issues ([1]) since the 15.0.2 release.
The release is available now from our website and [2]:
http://arrow.apache.org/install/
Read about what's new in the release
https://arrow.apache.org/blog/2024
12 matches
Mail list logo
