Why not? You can define alias for the ns => ::foo/bar

What about for cases where the attribute represents a to-many relationship?

(ns com.example.model.account ...)

(defattr ordered-item-names :com.example.model.account.ordered-item/names :ref

Maybe I should just be creating an attribute that returns ordered-item ids, and then letting the resolver figure out the associated names of the ordered items, instead of trying to fit the ordered item names into the account model?

> Maybe I should just be creating an attribute that returns ordered-item ids, and then letting the resolver figure out the associated names of the ordered items... This sounds more like it. But if it's performance critical you might want to measure it anyway. A simple resolver that queries the DB directly and returns what you need might also be a good idea. That said, imho there's nothing inherently wrong with your attribute above. I use plenty of "virtual" attributes like this

I think the one "wrong" thing is that it doesn't map directly to the filesystem. So far, I've been using auto-resolved kws and the mappings always line up... but if I tack something at the end of model.foo like model.foo.baz, it violates that convention. Of course, conventions are optional, but it seems like a good one to me.

I haven't quite into the groove with Pathom yet. A lot of it, for me, seems to come down to properly naming things. Usually when I have an a-ha moment, I end up renaming something, it all becomes simpler, and I realize I over-complicated the heck out of things in the first place.

well, you can always add another xxxx.ordered-item file/ns and go from there if it's worth it to you. I get what you mean though. If you aren't super strict about a particular naming convention you could also go with :com.example.model.account/ordered-item-names.

Hehe, i think that's true for every development task

That's exactly what I have right now. Got things to a working stage and just trying to do a little cleanup. The account/ordered-item-names approach feels sloppy in my code.

I end up with a bunch of account/ordered-item-x. Makes me think I'm not using Pathom to its potential or my stuff just isn't organized properly. Probably a bit of both 😛

Do you have more attributes / keywords like this? I think once you've aggregated a number of these it's easier to get a sense of what "feels correct" for you. It's probably not worth it to spend many hours thinking about a single keywords place

> I end up with a bunch of `account/ordered-item-x`. Yeah that sounds like you're not using pathom like you should

your ordered-items on account are a ref to another entity right? So the account/ordered-items attribute or resolver should just return their ids and all other attributes should reside in an ordered-items namespace. pathom will figure things out for you

Yeah, there's a m2m relation between accounts and items, through orders.

So that means 3 namespaces

(ns bla.account)

(defattr orders :bla.account/orders :ref ...)
(defresolver ordered-items ....)

(ns bla.order)
(defattr order-id...)
(defattr ordered-items...)

(ns bla.item)
(defattr item-id ...)
(defattr item-name ...)

Yep, more or less.

You can think of the ordered-items resolver as a helper for pathom, so you can call the resolver with an order-id, then go straight to your database, fetch all the items and return them (or just their id's, depending on what you want to do)

This resolver could then be used like this:

[{[:bla.account 123]
   [{:bla.account/ordered-items [:item/name ...]}]

Yeah, once it gets the ids it should be able to walk the graph to the rest of the requested attributes without needing specific resolvers.

exactly

I think it makes sense. Thanks @U012ADU90SW. I'll try to factor things down a bit tomorrow and reflect on why I made it so complicated...

Even so, you don't actually need a resolver if you already have a :ref attribute to orders in place, but your query would look more involved

Sure thing, good luck! Hope it made sense 😉

Well, in my case many of these are calling the same DB query function with different parameters for sorting.. to get the earliest or the latest item - things like that. So, I think I still need resolvers or at least attributes with ao/pc-resolve.

Great discussion!