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

[C#] Schema should be optional on FlightInfo #43672

Closed
ndglover opened this issue Aug 13, 2024 · 7 comments
Closed

[C#] Schema should be optional on FlightInfo #43672

ndglover opened this issue Aug 13, 2024 · 7 comments

Comments

@ndglover
Copy link
Contributor

Describe the enhancement requested

Similar to 37553

The idea being that the Schema is not a required field for FlightInfo. The Schema can be sent as part of the messages in the subsequent request.

Component(s)

C#

@kou kou changed the title Schema should be optional on FlightInfo [C#] Schema should be optional on FlightInfo Aug 13, 2024
CurtHagenlocher pushed a commit that referenced this issue Sep 4, 2024
### Rationale for this change

Schema is not required on a FlightInfo message and sometimes needs to be lazily evaluated on the server. This PR allows schema to be null on the FlightInfo since it will be picked up later when requests with those tickets are made.

### What changes are included in this PR?

### Are these changes tested?
Yes, added a test to confirm this behaviour

### Are there any user-facing changes?

* GitHub Issue: #43672

Authored-by: neilglover <neilglover@gmail.com>
Signed-off-by: Curt Hagenlocher <curt@hagenlocher.org>
@CurtHagenlocher CurtHagenlocher added this to the 18.0.0 milestone Sep 4, 2024
@CurtHagenlocher
Copy link
Contributor

Issue resolved by pull request 43673
#43673

zanmato1984 pushed a commit to zanmato1984/arrow that referenced this issue Sep 6, 2024
…43673)

### Rationale for this change

Schema is not required on a FlightInfo message and sometimes needs to be lazily evaluated on the server. This PR allows schema to be null on the FlightInfo since it will be picked up later when requests with those tickets are made.

### What changes are included in this PR?

### Are these changes tested?
Yes, added a test to confirm this behaviour

### Are there any user-facing changes?

* GitHub Issue: apache#43672

Authored-by: neilglover <neilglover@gmail.com>
Signed-off-by: Curt Hagenlocher <curt@hagenlocher.org>
@acceleanu
Copy link

Is it possible to have a release candidate for this fix?

@CurtHagenlocher
Copy link
Contributor

Is it possible to have a release candidate for this fix?

There's no existing process by which prereleases get published to nuget.org, so if you need something before the final 18.0.0 release you'd need to build it yourself from source.

khwilson pushed a commit to khwilson/arrow that referenced this issue Sep 14, 2024
…43673)

### Rationale for this change

Schema is not required on a FlightInfo message and sometimes needs to be lazily evaluated on the server. This PR allows schema to be null on the FlightInfo since it will be picked up later when requests with those tickets are made.

### What changes are included in this PR?

### Are these changes tested?
Yes, added a test to confirm this behaviour

### Are there any user-facing changes?

* GitHub Issue: apache#43672

Authored-by: neilglover <neilglover@gmail.com>
Signed-off-by: Curt Hagenlocher <curt@hagenlocher.org>
@ndglover
Copy link
Contributor Author

@CurtHagenlocher do you have a date for the 18.0.0 release?

@CurtHagenlocher
Copy link
Contributor

Code freeze is at the end of September and the release will be sometime during October. We can't really predict a date because it depends in part on how the testing goes.

@ndglover
Copy link
Contributor Author

ndglover commented Sep 16, 2024

Is there a reason not to have release candidates before that final release? It would seem to make sense from a stability perspective and also from an end user perspective. Waiting at worse case an entire quarter seems sub-optimal and each person then needs to fork the repo and manage builds etc

Happy to make a contribution if that's a good idea but not sure what would be involved.

@CurtHagenlocher
Copy link
Contributor

Yes, there are absolutely one or more official release candidates that are used for testing. I believe these would even be signed, if that's an issue. They are not, however, published to nuget.org. As I understand it, doing so would likely be a significant process change because I think the release candidates are exactly that: something that will be released and published if testing is successful -- versus artifacts that have been explicitly marked as non-release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants