feat(query): Procedure support drop if exists and create or replace

[TCeason]

I hereby agree to the terms of the CLA available at: https://docs.databend.com/dev/policies/cla/

Summary

• support drop procedure if exists
• support create or replace procedure

Part of #16501

Tests

• Unit Test
• Logic Test
• Benchmark Test
• No Test - Explain why

Type of change

• Bug Fix (non-breaking change which fixes an issue)
• New Feature (non-breaking change which adds functionality)
• Breaking Change (fix or feature that could cause existing functionality not to work as expected)
• Documentation Update
• Refactoring
• Performance Improvement
• Other (please describe):

---

This change is 

[BohuTANG]

Also need the syntax CREATE [ OR REPLACE ] PROCEDURE <name> ...

[TCeason]

Also need the syntax CREATE [ OR REPLACE ] PROCEDURE <name> ...

Yes create or replace already in plan. #16501

[drmingdrmer]

Reviewed 5 of 7 files at r1, 2 of 2 files at r2, 1 of 1 files at r3, all commit messages.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @sundy-li and @TCeason)

---

src/query/management/src/procedure/procedure_mgr.rs line 94 at r2 (raw file):

                    } else {
                        Err(AppError::from(name_ident.unknown_error(func_name!())).into())
                    }

IMHO, CreateOrReplace does not expect an unknown error. If there is no such record, it should just create one.

The above create_id_value() should be already enough. I do not get why this update_id_value is requried.

Code quote:

                    let res = self
                        .kv_api
                        .update_id_value(name_ident, meta.clone())
                        .await?;

                    if let Some((id, _meta)) = res {
                        Ok(CreateProcedureReply { procedure_id: *id })
                    } else {
                        Err(AppError::from(name_ident.unknown_error(func_name!())).into())
                    }

---

src/query/management/src/procedure/procedure_mgr.rs line 120 at r2 (raw file):

                return Err(AppError::from(name_ident.unknown_error("drop procedure")).into());
            }
        }

The if_exists flag only affects the response to the client; it does not influence operations on the meta-service.

This if_exists check should be moved up the call stack to the point where an Error response is actually required, either in the immediate caller or a higher-level caller.

Adn DropProcedureReq does not need if_exists at all.

Code quote:

        if dropped.is_none() {
            if req.if_exists {
                // Ok
            } else {
                return Err(AppError::from(name_ident.unknown_error("drop procedure")).into());
            }
        }

[TCeason]

Reviewed 5 of 7 files at r1, 2 of 2 files at r2, 1 of 1 files at r3, all commit messages.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @sundy-li and @TCeason)

src/query/management/src/procedure/procedure_mgr.rs line 94 at r2 (raw file):

                    } else {
                        Err(AppError::from(name_ident.unknown_error(func_name!())).into())
                    }

IMHO, CreateOrReplace does not expect an unknown error. If there is no such record, it should just create one.

The above create_id_value() should be already enough. I do not get why this update_id_value is requried.

Code quote:

                    let res = self
                        .kv_api
                        .update_id_value(name_ident, meta.clone())
                        .await?;

                    if let Some((id, _meta)) = res {
                        Ok(CreateProcedureReply { procedure_id: *id })
                    } else {
                        Err(AppError::from(name_ident.unknown_error(func_name!())).into())
                    }

src/query/management/src/procedure/procedure_mgr.rs line 120 at r2 (raw file):

                return Err(AppError::from(name_ident.unknown_error("drop procedure")).into());
            }
        }

The if_exists flag only affects the response to the client; it does not influence operations on the meta-service.

This if_exists check should be moved up the call stack to the point where an Error response is actually required, either in the immediate caller or a higher-level caller.

Adn DropProcedureReq does not need if_exists at all.

Code quote:

        if dropped.is_none() {
            if req.if_exists {
                // Ok
            } else {
                return Err(AppError::from(name_ident.unknown_error("drop procedure")).into());
            }
        }

Ok, we can refactor these two function. e.g. add update_procedure API. If is replace , call update.

[drmingdrmer]

Reviewed 4 of 6 files at r6, all commit messages.
Reviewable status: 10 of 12 files reviewed, 4 unresolved discussions (waiting on @sundy-li and @TCeason)

---

src/query/service/src/interpreters/interpreter_procedure_create.rs line 62 at r6 (raw file):

        let _ = UserApiProvider::instance()
            .add_procedure(&tenant, create_procedure_req, overriding)
            .await?;

The returned result should be consumed: with CreateOption::CreateIfNotExists, no error should be returned.

Code quote:

        let overriding = self.plan.create_option.is_overriding();

        let _ = UserApiProvider::instance()
            .add_procedure(&tenant, create_procedure_req, overriding)
            .await?;

[drmingdrmer]

The logic looks good to me. And I'd suggest avoiding using ErrorCode if possible.

Reviewed 11 of 11 files at r8, all commit messages.
Reviewable status: all files reviewed, 5 unresolved discussions (waiting on @sundy-li and @TCeason)

---

src/query/service/src/interpreters/interpreter_procedure_create.rs line 71 at r8 (raw file):

                return Err(e);
            }
        }

I'd suggest avoid using ErrorCode if possible. ErrorCode includes all kind of errors that makes it difficult to distinguish(by enumerate every of them) RPC error or logic error like PROCEDURE_ALREADY_EXISTS.

If add_procedure() returns KVAppError or Result<Result<..>>, the error handling like this would be easier.

Such as with Result<Result<T, LogicError>, MetaError>, a simple ? will filter out meta service errors that are not interested.

Code quote:

        if let Err(e) = UserApiProvider::instance()
            .add_procedure(&tenant, create_procedure_req, overriding)
            .await
        {
            if !(self.plan.create_option == CreateOption::CreateIfNotExists
                && e.code() == ErrorCode::PROCEDURE_ALREADY_EXISTS)
            {
                return Err(e);
            }
        }

[TCeason]

The logic looks good to me. And I'd suggest avoiding using ErrorCode if possible.

Reviewed 11 of 11 files at r8, all commit messages.
Reviewable status: all files reviewed, 5 unresolved discussions (waiting on @sundy-li and @TCeason)

src/query/service/src/interpreters/interpreter_procedure_create.rs line 71 at r8 (raw file):

                return Err(e);
            }
        }

I'd suggest avoid using ErrorCode if possible. ErrorCode includes all kind of errors that makes it difficult to distinguish(by enumerate every of them) RPC error or logic error like PROCEDURE_ALREADY_EXISTS.

If add_procedure() returns KVAppError or Result<Result<..>>, the error handling like this would be easier.

Such as with Result<Result<T, LogicError>, MetaError>, a simple ? will filter out meta service errors that are not interested.

Code quote:

        if let Err(e) = UserApiProvider::instance()
            .add_procedure(&tenant, create_procedure_req, overriding)
            .await
        {
            if !(self.plan.create_option == CreateOption::CreateIfNotExists
                && e.code() == ErrorCode::PROCEDURE_ALREADY_EXISTS)
            {
                return Err(e);
            }
        }

Like this: 7213781?

Maybe we can refactor all procedure API in next pr that support alter procedure name?

[drmingdrmer]

Like this: 7213781?

Maybe we can refactor all procedure API in next pr that support alter procedure name?

Yes, It would be alright with another PR:)

In the code snippet above, the outer Result should be a std::result::Result with MetaError as its error type. The current ErrorCode Result combines both logical errors and RPC errors, which can lead to confusion for the caller. Separating these error types will provide clearer error handling and improve the API's usability.

[TCeason]

Also need the syntax CREATE [ OR REPLACE ] PROCEDURE <name> ...

I think we can merge this pr now. cc @BohuTANG

[drmingdrmer]

Reviewed 2 of 2 files at r9, all commit messages.
Reviewable status: all files reviewed, 4 unresolved discussions (waiting on @sundy-li and @TCeason)