Skip to content

Conversation

@amogh-jahagirdar
Copy link
Contributor

Which issue does this PR close?

  • Closes #.

What changes are included in this PR?

Are these changes tested?

@amogh-jahagirdar amogh-jahagirdar force-pushed the server-supported-endpoints branch from 36792b0 to 5a54643 Compare December 26, 2025 00:58
/// Check if a table exists in the catalog.
async fn table_exists(&self, table: &TableIdent) -> Result<bool> {
let context = self.context().await?;
Endpoint::check_supported(&context.config.endpoints, Endpoint::v1_table_exists())?;
Copy link
Contributor

Choose a reason for hiding this comment

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

This may break compatibility with older implementations where table existence checks happened through LoadTable.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah that's why I left this in draft, I wanted to think through more how to handle this particular case. We have a choice here, either we say that the rust client needs to work with those older servers so we take the complexity of not doing this strict check, or we opt for a cleaner solution which has some stricter assumptions.

I don't think it's too much extra work to handle the compatibility so I'd probably just address it.

| Method::DELETE
| Method::HEAD
| Method::OPTIONS
| Method::PATCH => {}
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we scope this down to the methods we actually handle?

Copy link
Contributor Author

@amogh-jahagirdar amogh-jahagirdar Jan 4, 2026

Choose a reason for hiding this comment

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

We could, I'm not opposed to that but I also think if someone adds the usage of these HTTP methods to the spec later, it creates another point in the client code that needs to be updated at that point, instead of "just working".

I figured since the REST spec is just defined from HTTP standard verbs, just allow all of the standard ones.

fn default_endpoints() -> &'static HashSet<Endpoint> {
DEFAULT_ENDPOINTS.get_or_init(|| {
[
Endpoint::v1_config(),
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: we can remove config from this list

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes! good point, it's implicit that config is supported.

Comment on lines +763 to +770
eprintln!(
"DEBUG: endpoints value in load_table: {:?}",
context.config.endpoints
);
eprintln!(
"DEBUG: looking for endpoint: {:?}",
Endpoint::v1_load_table()
);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Need to clean this up

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants