Fork me on GitHub
#fulcro
<
2021-10-14
>
roklenarcic13:10:06

It might be practical to add a function with a short name to com.fulcrologic.rad.attributes to extract qualified-key from an attribute… often when specifying ao/target, ao/identities and such I would rather reference the attribute var instead of specifying the keyword directly.

Jakub Holý (HolyJak)15:10:40

Is (::attr/qualified-key myattribute) too long? I guess you could have (attr/kwd myattribute) but you could just as well make the function yourself...

1
tony.kay17:10:42

I think he’s asking for attribute-options…so it would be ao/qualified-key…which I agree should be there. I just never added it.

tony.kay17:10:20

Released in 1.0.27….I’d been meaning to do that for some time.

roklenarcic14:10:24

How would you model many-to-many relationship with extra properties in RAD attributes? Let’s say you’ve got accounts and users, where each user can be a member of many accounts and each account can have many users. But there’s also the data of user’s role in the account (so many-to-many with additional data on each link). I am unsure what’s the best way to model this in attribute based model

Jakub Holý (HolyJak)15:10:20

Unsure as well. I guess user has :user/accounts , account has :account/user-roles and there is user-role with :user-role/user and :user-role/role ? It depends I guess on how you want to use these attributes and how it is represented in your database... Not sure there is single, universal answer

tony.kay17:10:38

So, remember that a ref many is already a many-to-many unless there is a unique constraint. There is nothing special about modeling it w/attributes, though you may want extra “made up” indicators for your database layer to use if it is creating schema….but, if you don’t need that (which you don’t with Datomic), then it is a simple problem. For example: User - an entity representing things like email/name Account - The thing(s) a user can access. Has many access records. (also has an “owner”, which is a to-one to a single user that created the account, but that is beside the point for the M-to-M question) AccessRecord - A record that has a to-one User, and a list of permissions In this case the access record is a join between a user and permissions. The account owns the access record(s) and can therefore grant many users access…but a user isn’t owned by an account (an account has a single creator, which is considered the owner of that account), and therefore can be part of many accounts. The extra info of permissions is stored in the access record.

tony.kay17:10:37

So, from a purist standpoint the attribute model, barring any explicit unique constraint, is already implicitly capable of many-to-many…adding in more data is just choosing the right spot to put that data.

roklenarcic18:10:12

In my case the data is inherently on the many to many connection, not on something else. I ended up actually making a AccountUser entity to model many-to-many, because I really don’t see how else this could work. What you wrote assumes I am only interest in roles in one direction, but I am in both. So the user needs a list of accounts with role in the account and accounts need a list of users with their roles in the account.

tony.kay19:10:04

What you’re talking about is satisfied by the fact that a query can assemble the data as necessary. My point is that a many-to-many is trivial to model. Edges are “bidirection” by their nature…there is a relationship between things that can be queried. HOW you query it is database specific.

roklenarcic20:10:10

I guess I’ll need take a while to grok this modelling, thanks