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

simplify internal visibility by replacing conditional flags with pub(crate) prefixes #672

Open
sebastiantia opened this issue Jan 31, 2025 · 0 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@sebastiantia
Copy link
Collaborator

we can define the default visibility of delta internals by prefixing the struct/fn/... with pub(crate) instead of #[cfg_attr(not(feature = "developer-visibility"), visibility::make(pub(crate)))]. This simplifies the codebase.

Examples:

#[cfg_attr(not(feature = "developer-visibility"), visibility::make(pub(crate)))]

#[cfg_attr(not(feature = "developer-visibility"), visibility::make(pub(crate)))]

and many more...

@sebastiantia sebastiantia added enhancement New feature or request good first issue Good for newcomers labels Jan 31, 2025
@sebastiantia sebastiantia changed the title Replace #[cfg_attr(not(feature = "developer-visibility"), visibility::make(pub(crate)))] with pub(crate)s simplify internal visibility by replacing conditional flags with pub(crate) prefixes Jan 31, 2025
sebastiantia added a commit that referenced this issue Feb 5, 2025
<!--
Thanks for sending a pull request!  Here are some tips for you:
1. If this is your first time, please read our contributor guidelines:
https://github.com/delta-incubator/delta-kernel-rs/blob/main/CONTRIBUTING.md
2. Run `cargo t --all-features --all-targets` to get started testing,
and run `cargo fmt`.
  3. Ensure you have added or run the appropriate tests for your PR.
4. If the PR is unfinished, add '[WIP]' in your PR title, e.g., '[WIP]
Your PR title ...'.
  5. Be sure to keep the PR description updated to reflect all changes.
-->

<!--
PR title formatting:
This project uses conventional commits:
https://www.conventionalcommits.org/

Each PR corresponds to a commit on the `main` branch, with the title of
the PR (typically) being
used for the commit message on main. In order to ensure proper
formatting in the CHANGELOG please
ensure your PR title adheres to the conventional commit specification.

Examples:
- new feature PR: "feat: new API for snapshot.update()"
- bugfix PR: "fix: correctly apply DV in read-table example"
-->



## What changes are proposed in this pull request?
<!--
Please clarify what changes you are proposing and why the changes are
needed.
The purpose of this section is to outline the changes, why they are
needed, and how this PR fixes the issue.
If the reason for the change is already explained clearly in an issue,
then it does not need to be restated here.
1. If you propose a new API or feature, clarify the use case for a new
API or feature.
  2. If you fix a bug, you can clarify why it is a bug.
-->

This PR introduces the `Sidecar` action and its associated
`SidecarVisitor`.

This action and visitor is used for the V2 checkpoints Reader/Writer
table feature.

Edge cases:
- If a batch of actions includes two sidecar actions referencing the
same file, issue a warning. We will not throw an error; instead, we will
ignore the duplicate file path to prevent unnecessary re-reading of the
file.
- Error if the sidecar `path` field is a full file-path instead of just
the filename. Ref to issue:
#675

resolves #668

<!--
Uncomment this section if there are any changes affecting public APIs:
### This PR affects the following public APIs

If there are breaking changes, please ensure the `breaking-changes`
label gets added by CI, and describe why the changes are needed.

Note that _new_ public APIs are not considered breaking.
-->

Note: PR also simplifies some conditional flags detailed in issue:
#672



## How was this change tested?
<!--
Please make sure to add test cases that check the changes thoroughly
including negative and positive cases if possible.
If it was tested in a way different from regular unit tests, please
clarify how you tested, ideally via a reproducible test documented in
the PR description.
-->


- Ensure schema projection to `Sidecar` works
- Ensure that the visitor correctly extracts `Sidecar` actions
~- Ensure duplicate `paths` in sidecar actions are ignored~
~- Ensure `VisitorError` is returned when full file path is passed in
`path` field~
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

1 participant