Improve search parameters?

[FlixCoder]

• Allow multiple values
• more builder-style
• ?

[SHA888]

Hi @FlixCoder,

I’d like to contribute to this issue! To clarify, are you looking for a way to allow users to add multiple values to search parameters using a more ergonomic, builder-style API (e.g., method chaining or fluent interface)?

If so, my initial idea is to extend the search parameter builder to support methods like .add_param("name", "value1") and .add_param("name", "value2"), or perhaps accept a vector of values for a single parameter. This would make it easier to construct complex queries in a more Rust-idiomatic way.

Is this approach aligned with what you have in mind, or do you have any preferences or additional requirements? If the issue is available, I’d be happy to start working on a proposal!

Thanks!

[FlixCoder]

Thank you again! :D

After trying to remember, I think I created this issue for the following reasons:

• I just quickly added search parameters for every search type/variant mentioned in the spec.
• But I have put more effort into some that I needed of that I would think are used more frequently. So it might be that some types are easier or more complete than others.
• I wanted to support both the very simple search cases with a very quick and easy API/usage, but also allow for more complex queries somehow, if that even makes sense to create, if you can already add raw search parameters via (key, value).
• I wanted the decision to be somewhat driven by actual use cases, but I have not done too much myself lately and have not heard any complaints yet, so everything might be fine ^^

So it might be a bit difficult to know what exactly to work on here and how. I am not against any proposal for a better solution, but if the benefit is small or I don't like it, I would probably keep the current implementation for now. Would also have to think whether it makes sense to make backwards compatibility claims at some point, but probably not yet?

I'd say don't put in too much effort here, without discussing first.

[SHA888]

Hi @FlixCoder,

Based on our previous discussion about improving search parameters, I've drafted a lightweight, backwards-compatible enhancement to the SearchParameters API.

Proposed addition:

impl SearchParameters {
    /// Add multiple values for a single parameter
    /// 
    /// Example:
    /// ```rust
    /// let params = SearchParameters::empty()
    ///     .and_values("name", vec!["John", "Jane"])
    ///     .and_values("status", vec!["active", "pending"]);
    /// ```
    #[must_use]
    pub fn and_values<P, V>(mut self, parameter: P, values: Vec<V>) -> Self
    where
        P: Into<String>,
        V: ToString,
    {
        // Join multiple values with comma, following FHIR search spec
        let joined_values = values.into_iter()
            .map(|v| v.to_string())
            .collect::<Vec<_>>()
            .join(",");
        
        self.queries.push((parameter.into(), joined_values));
        self
    }
}

Key features:

• Optional method, doesn't break existing code
• Supports multiple values in a builder-style
• Follows FHIR specification for comma-separated values
• Minimal, intuitive implementation

What are your thoughts? Would this approach meet the goals you had in mind when creating the issue?

[FlixCoder]

Oh, I actually didn't intend to do something to the SearchParameters type, but to the sub-types like NumberSearch. So for each of them, depending on the spec, possible multiple values or something.

The raw search parameter strings can already be constructed for multiple values as well, I don't think there is need for another method.

[SHA888]

Hi @FlixCoder

Thanks for the clarification! I appreciate you explaining that the current implementation already supports the flexibility you were looking for. The existing methods for raw search parameter strings and the sub-types like NumberSearch seem to provide the necessary functionality.

If you have any specific use cases in the future that aren't covered, please don't hesitate to reopen the discussion.

Cheers! 👍