Skip to content

ARROW-16085: [C++][R] InMemoryDataset::ReplaceSchema does not alter scan output - #13088

Closed
wjones127 wants to merge 5 commits into
apache:masterfrom
wjones127:ARROW-16085-unify-inmemory-datasets
Closed

ARROW-16085: [C++][R] InMemoryDataset::ReplaceSchema does not alter scan output#13088
wjones127 wants to merge 5 commits into
apache:masterfrom
wjones127:ARROW-16085-unify-inmemory-datasets

Conversation

@wjones127

@wjones127wjones127 commented May 6, 2022

Copy link
Copy Markdown
Member

Feels a little funny that deleting this code just makes it work, so I added a decent number of tests to make sure differing schemas are handled. LMK if you think I missed something.

@github-actions

Copy link
Copy Markdown

@github-actions

Copy link
Copy Markdown

⚠️ Ticket has not been started in JIRA, please click 'Start Progress'.

@wjones127
wjones127 marked this pull request as ready for review May 6, 2022 21:52
@lidavidm

Copy link
Copy Markdown
Member

The other way (arguably) would be to have ReplaceSchema project the batches (though that is a lot more work).


ASSERT_OK_AND_ASSIGN(scanner_builder, dataset->NewScan());
ASSERT_OK_AND_ASSIGN(scanner, scanner_builder->Finish());
ASSERT_NOT_OK(scanner->ToTable());

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we have a more explicit check, e.g. with EXPECT_RAISES_WITH_MESSAGE_THAT?

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah it was raising NotImplemented, but I realized we probably would rather raise TypeError, so I added a check for project-ability where the schema consistency check was before.

auto batch2 = ConstantArrayGenerator::Zeroes(kBatchSize, schema_);
RecordBatchVector batches{batch1, batch2};

auto dataset = std::make_shared<InMemoryDataset>(schema_, batches);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we actually want this to be valid though? I would expect the batches of a dataset to have a consistent schema

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In file fragments, it's totally normal to have a physical schema that is different from the dataset schema.

This came up when I realized we could create a union dataset out of filesystem ones but not in-memory ones if the schemas differed.

The other way (arguably) would be to have ReplaceSchema project the batches (though that is a lot more work).

I thought about that, but then are we materializing the projected batches before any scan is started? It seems more efficient for the projection to happen as part of the scan.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, good point about the fragments.

I was thinking InMemoryDataset already has all the data in memory, so it's not a big deal anyways. But yes, that's unnecessary work compared to this.

" which did not match InMemorySource's: ", *schema);
}

RETURN_NOT_OK(CheckProjectable(*schema, *batch->schema()));

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels like this could be a construction-time check to avoid repeated checking except there is no way to return a Status there, unfortunately. (Not a big deal, though.)

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about that, but would have to change this to a ::Make() method and didn't want to go that far here.

@ursabot

Copy link
Copy Markdown

Benchmark runs are scheduled for baseline = 35119f2 and contender = 5b653ee. 5b653ee is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Finished ⬇️0.0% ⬆️0.0%] ec2-t3-xlarge-us-east-2
[Failed ⬇️0.31% ⬆️0.0%] test-mac-arm
[Finished ⬇️0.71% ⬆️0.0%] ursa-i9-9960x
[Finished ⬇️0.12% ⬆️0.0%] ursa-thinkcentre-m75q
Buildkite builds:
[Finished] 5b653ee2 ec2-t3-xlarge-us-east-2
[Failed] 5b653ee2 test-mac-arm
[Finished] 5b653ee2 ursa-i9-9960x
[Finished] 5b653ee2 ursa-thinkcentre-m75q
[Finished] 35119f29 ec2-t3-xlarge-us-east-2
[Finished] 35119f29 test-mac-arm
[Finished] 35119f29 ursa-i9-9960x
[Finished] 35119f29 ursa-thinkcentre-m75q
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python, R. Runs only benchmarks with cloud = True
test-mac-arm: Supported benchmark langs: C++, Python, R
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java

@wjones127
wjones127 deleted the ARROW-16085-unify-inmemory-datasets branch May 11, 2022 22:43
kou pushed a commit that referenced this pull request Feb 20, 2023
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@wjones127@lidavidm@ursabot