Associated const attribute names

[softprops]

💡 Feature description

When composing queries you refer to items attribute names. A derived item has access to these names. To make queries less error prone, let's define associated constants for each attribute name

💻 Basic example

[softprops]

Tbs assuming these would be associated consts what would the name casing be. The same as struct fields or transformed LikeThis. Also is it too naive to leave these as static strs. Should these have a type which expose other data? What would that data be?

[rimutaka]

Name casing - not that critical, as long as there are no warnings. Can you give an example of what that query code may look like?

[softprops]

Basically anywhere you'd type out the name of a field already declared in Item type struct as a str I'd like to remove human error and give ide's the declared name instead. It fields weird to type these out as strings knowing the values are known.

It seems conventional to follow these guidelines https://rust-lang.github.io/api-guidelines/naming.html of these are associated consts so that may be best.

What's also potentially useful is when the value does not align with the actual field. Let say you have an item field customer_id in rust but renamed to CustomerID in ddb. You have a 50 50 chance you'll get it right even if you type correctly.

Naming aside, I'm wondering this should be a type va str value. The concern which I don't want to weigh too heavily is at some future date I have an aha moment and want to store more information than the field name in these values.

I'm happy to iterate but the primary goal is remove human err and make ide auto complete dx nice. Everything else at this point is not well defined so it's secondary

[softprops]

Also don't want this to feel to heavy. I don't want this to feel like an orm but more of a static type mapping over existing interfaces

[rimutaka]

I'm happy to give this a try some time next week, if you are not in a hurry with this feature. That will be me learning how to make / fix proc macros. :)

Is there anything else non-macro-related that needs fixing in dynomite or lambda-runtime? I looked through the issues, but nothing seems important enough, other than making more examples and maybe improving the docs.

[softprops]

I'm happy to give this a try some time next week, if you are not in a hurry with this feature.

Go for it. Mentioned about were the handful of factors to consider

Is there anything else non-macro-related that needs fixing in dynomite or lambda-runtime?

I'll see if I can put together more getting started issues