I opened https://issues.apache.org/jira/browse/ARROW-8079 about the
Python question
On Wed, Mar 11, 2020 at 2:53 PM Neal Richardson
wrote:
>
> While the underlying storage may allow duplicate keys, it seems much more
> likely that someone would end up with duplicate keys by accident than by
> des
While the underlying storage may allow duplicate keys, it seems much more
likely that someone would end up with duplicate keys by accident than by
design. And although it may be up to the implementations to determine or
enforce uniqueness constraints, it might be a good idea to make a
project-level
On Wed, Mar 11, 2020 at 2:22 PM Antoine Pitrou wrote:
>
> On Wed, 11 Mar 2020 12:44:26 -0500
> Wes McKinney wrote:
> > On this note, in Python we should probably re-evaluate the data
> > structure returned when accessing the "metadata" field.
>
> I think it's ok for the convenience API to return
On Wed, 11 Mar 2020 12:44:26 -0500
Wes McKinney wrote:
> On this note, in Python we should probably re-evaluate the data
> structure returned when accessing the "metadata" field.
I think it's ok for the convenience API to return a dict, if we also
expose e.g. a "metadata_items" that returns an it
On this note, in Python we should probably re-evaluate the data
structure returned when accessing the "metadata" field.
On Wed, Mar 11, 2020 at 12:42 PM Wes McKinney wrote:
>
> In the C++ library at least, uniqueness is never asserted when reading
> and writing the IPC metadata [1] [2]. If you us
In the C++ library at least, uniqueness is never asserted when reading
and writing the IPC metadata [1] [2]. If you use
KeyValueMetadata::FindKey and the keys are non-unique, it will return
the first one it finds. KeyValueMetadata::Merge assumes uniqueness,
and the KeyValueMetadata::ToUnorderedMap
