I was creating this ticket ARROW-17295 [1], but ended up unsure if this is
something we'd like to maintain, so I thought I would bring it up for
discussion. Essentially: should we expand the capabilities of our bundled
dependency system? Or should we constrain the scope and point users that
wish
Hi team!
2cents(maybe less): if I get the idea right, StringView data type might be
very handy/optimal for cases where users already have string data in some
other formats available (e.g. std::unordered_map, flat
buffer structures etc.) Off which record batches are created and shipped
to the
Le 03/08/2022 à 18:29, Jorge Cardoso Leitão a écrit :
Hi Antoine,
Thanks a lot for your answer.
So, if I understand (I may have not), we do not impose restrictions to the
alignment of the data when we get the pointer; only when we read from it.
Doesn't this require checking for alignment at
Hi Antoine,
Thanks a lot for your answer.
So, if I understand (I may have not), we do not impose restrictions to the
alignment of the data when we get the pointer; only when we read from it.
Doesn't this require checking for alignment at runtime?
Best,
Jorge
On Tue, Aug 2, 2022 at 6:59 PM
Hello All,
I am experiencing issues with finding documentation on .Net API of apache
arrow. Are there any examples or sample projects, that can be used for learning?
Currently I am trying to implement ability to append extra values to existing
primitives arrays, but I was not able to
Le 03/08/2022 à 16:19, Lee, David a écrit :
There are probably two ways to approach this.
Physically store the json as a UTF8 string
Or
Physically store the json as nested lists and structs.
This works if all JSON values follow a predefined schema, which is not
necessarily the case.
I think, from a compute perspective, one would just cast before doing
anything. So you wouldn't need much beyond parse and unparse. For
example, if you have a JSON document and you want to know the largest
value of $.weather.temperature then you could do...
There are probably two ways to approach this.
Physically store the json as a UTF8 string
Or
Physically store the json as nested lists and structs. This is more complicated
and ideally this method would also support including json schemas to help
address missing values and round trip
Thanks! Removing the "gs://" prefix indeed fixes it.
On Tue, Aug 2, 2022 at 4:01 PM Will Jones wrote:
> Hi Li Jin,
>
> I'm not sure yet what changed, but I believe you can fix that error simply
> by omitting the scheme prefix from the URI and just use the page when
> loading the dataset. Here's
CRAN is closed for new submissions until August 5, so I'll submit the R
package next week.
On Wed, Aug 3, 2022 at 7:19 AM Krisztián Szűcs
wrote:
> Below is the current status of the post release tasks, I
> "soft-assigned" a couple of them to the relevant maintainers, could
> you please help
Below is the current status of the post release tasks, I
"soft-assigned" a couple of them to the relevant maintainers, could
you please help with those?
- [done] Make the released version as “RELEASED” on JIRA
- [done] Start the new version on JIRA on the ARROW project
- [done] Upload source
-
Hi,
The vote carries with 4 +1 binding votes, 2 +1 non-binding votes and
no -1 votes.
I'm starting to work on the post-release tasks and keep this thread
updated about the current status.
Thanks everyone!
- Krisztian
On Wed, Aug 3, 2022 at 6:25 AM Yibo Cai wrote:
>
> +1 (binding)
>
> Verified
While I do like having a json type, adding processing functionality especially
around compute capabilities might be limiting.
Arrow already supports nested lists and structs which can cover json structures
while offering vectorized processing. Json should only be a logical
representation of
13 matches
Mail list logo
