Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Writing from a Delta table scan using WriteBuilder fails due to missing object store #1186

Closed
gruuya opened this issue Feb 27, 2023 · 0 comments · Fixed by #1187
Closed

Writing from a Delta table scan using WriteBuilder fails due to missing object store #1186

gruuya opened this issue Feb 27, 2023 · 0 comments · Fixed by #1187
Labels
bug Something isn't working

Comments

@gruuya
Copy link
Contributor

gruuya commented Feb 27, 2023

Environment

Delta-rs version: 0.7.0 (latest main)

Binding: Rust

Environment:

  • Cloud provider: N/A
  • OS: MacOS
  • Other:

Bug

What happened:

When performing a write into a delta table from a different delta table using the WriteBuilder::with_input_execution_plan, the write fails since the builder generates a new blank session/task context to go along with the execution plan.

This in turn leads to the loss of the object store registered for the scan previously, and consequently a failed write (No suitable object store found for delta-rs://...).

What you expected to happen:

A proper task context should be supplied when executing the input plan.

How to reproduce it:

See the test here for an example: #1187

More details:

@gruuya gruuya added the bug Something isn't working label Feb 27, 2023
@gruuya gruuya changed the title Writing from a Delta table scan using WriteTable fails due to missing object store Writing from a Delta table scan using WriteBuilder fails due to missing object store Feb 28, 2023
wjones127 pushed a commit that referenced this issue Mar 1, 2023
# Description
The session state can keep some context pertinent to the [input
plan](https://github.com/delta-io/delta-rs/blob/main/rust/src/operations/write.rs#L153-L157),
so passing it allows for building useful `TaskContext`s for executing
the plan.

This is especially the case when the input plan references another Delta
table, which has previously registered it's object store (that needs to
be accessible during the execution of the physical plan).

# Related Issue(s)
Closes #1186 

Curiously, if in the test I use `delta-0.8.0-partitioned` the final
`SELECT` query fails with:
```
External(Execution("Failed to map column projection for field year. Incompatible data types Dictionary(UInt16, Utf8) and Utf8"))
```
I'm not sure yet why this happens, but I think it has nothing to do with
this change.

# Documentation
chitralverma pushed a commit to chitralverma/delta-rs that referenced this issue Mar 17, 2023
# Description
The session state can keep some context pertinent to the [input
plan](https://github.com/delta-io/delta-rs/blob/main/rust/src/operations/write.rs#L153-L157),
so passing it allows for building useful `TaskContext`s for executing
the plan.

This is especially the case when the input plan references another Delta
table, which has previously registered it's object store (that needs to
be accessible during the execution of the physical plan).

# Related Issue(s)
Closes delta-io#1186 

Curiously, if in the test I use `delta-0.8.0-partitioned` the final
`SELECT` query fails with:
```
External(Execution("Failed to map column projection for field year. Incompatible data types Dictionary(UInt16, Utf8) and Utf8"))
```
I'm not sure yet why this happens, but I think it has nothing to do with
this change.

# Documentation
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant