Collection validation should check `field` property of composite attributes about electrodb HOT 2 OPEN

Hi @raryanpur 👋

Thanks for submitting this! Ultimately the reason this validation exists on the attribute name (as opposed to the field) is because the attribute name is what's used when performing a collection query. The validation prevents ambiguity around which attributes must be provided to perform the query, and keeps the api simple. For example, if the entities you included were not validated this way, which query would be correct?

service.collections.patrons({ restaurantId: 'wendys' }).go();  

service.collections.patrons({ id: 'wendys' }).go();  

service.collections.patrons({ id: 'wendys', restaurantId: 'wendys' }).go();  

Going a step further, if the "customer" entity was defined with an id field as well (which I think would be likely with this pattern, then id it gains additional ambiguity:

{
    model: {
        entity: "customer",
        service: "app",
        version: "1"
    },
    attributes: {
        id: {
            type: "string"
        },
        restaurantId: {
            type: "string"
        },
        name: {
            type: "string"
        }
    },
    indexes: {
        record: {
            collection: "patrons"
            pk: {
                field: "pk",
                composite: ["restaurantId"],
            },
            sk: {
                field: "sk",
                composite: ["id"],
            },
        }
    }
}

These are just a few examples to illustrate why the library optimizes a bit more for simplicity here. The typing system also benefits from this approach, which is a top priority for the library. Definitely share any thoughts you have about the above however, the more brains on this topic the better because it has come up before!

from electrodb.

Thanks for the info! Need some time to digest but makes sense on first pass 👍🏼

from electrodb.