DynamoDB expression builder feature

[abusch]

Hi, I came across #570 and I also agree this feature would be great to have. As it turns out, we (my team at IDVerse) have some code internally that (at least partially) fills that need, and we're wondering if it's something we could contribute back in some form. I guess at this point I would just like to get the discussion started and ask a few questions about the general process:

• is the RFC process described somewhere?
• are there some constraints/guidelines in terms of API?
  • I assume not introducing 3rd-party dependencies would be one (at least not in the public API?).
  • Does it need to take inspiration from the same feature in other languages? I know there's one in the golang SDK, something kind of similar in the Java one (in a separate library it seems?). I don't know if the SDK for other languages have that feature...

At the moment, our api is fairly simple, and basically consists of an enum like the following:

pub enum ConditionExpression {
    /// True if any of the specified conditions evaluates to true.
    Or(Vec<ConditionExpression>),
    /// True if all of the specified conditions evaluate to true.
    And(Vec<ConditionExpression>),
    /// True if the specified condition evaluates to false.
    Not(Box<ConditionExpression>),
    /// True if the attribute value is equal to the specified value.
    Eq(String, AttributeValue),
    /// True if the attribute value is equal to the value of the second attribute.
    EqAttr(String, String),
   ...
}

and a pub fn into_expression(self, names: &mut AutoExpressionNames) -> String method to generate the condition expression in string form. The AutoExpressionNames type is a helper class we use to keep track of attribute names/values found in the expression to generate placeholders and generate the values for the set_expression_attribute_names() and set_expression_attribute_values() methods.

It's not very builder-like at the moment 😅, but I'm sure it could be wrapped into a more friendly builder interface.

On top of the above use case, we have additional functionality that is useful for us when writing tests. For instance, the above enum also has a pub fn matches_item(&self, item: HashMap<String, &AttributeValue>) -> bool that checks if the current condition matches the given item, in a similar way that DynamoDB itself would do when filtering results. I'm not sure if that kind of functionality would fit here, but if not, that could be moved out into our own separate trait I suppose.

Anyway, I just wanted to get the discussion started. Let me know what you think!