Ash Framework•3mo ago

Manual relationship in belongs_to

Hi! Is there any reason there is no way to have a manual relationship in a belongs_to block? Is it because that one by default creates the attribute? I'm doing a Stripe wrapper that generates custom dependencies, and some relationships are belongs_to-like and some are has_*-like. And would love to preserve the semantics.

13 Replies

barnabasj•3mo ago

I'm not 100% about the reasoning. Why do you need a manual relationship?

mcollOP•3mo ago

In order to keep the integrations simple all my stripe resources are basically two attributes, stripe_id and stripe_resource, which is a :map of the given json response. I still want to be able to create relationships so I know a customer subscriptions for example. I do that through two things: * Generate custom indexes on json fields (stripe_resrouce ->>'customer' for a subscription for example). * A manual relationship that builds the queries For example in subscription I have

    has_one :customer, Katarineko.Payments.Customer do
      manual {StripeRelationship, field: ["customer"], type: :belongs_to}
    end

    has_one :customer, Katarineko.Payments.Customer do
      manual {StripeRelationship, field: ["customer"], type: :belongs_to}
    end

this relates to the customer resource, that wraps the stripe customer through stripe_resource->>'customer'. This should be a belongs_to since the relationship attribute is in this resource. I also have

    custom_indexes do
      index ["(stripe_resource->>'customer')"], unique: false, name: "subscriptions_stripe_customer"
    end

    custom_indexes do
      index ["(stripe_resource->>'customer')"], unique: false, name: "subscriptions_stripe_customer"
    end

To be able to have the reverse has_many relationship from customer

    has_many :subscriptions, P.Subscription do
      manual {StripeRelationship, field: ["customer"]}
    end

    has_many :subscriptions, P.Subscription do
      manual {StripeRelationship, field: ["customer"]}
    end

barnabasj•3mo ago

🤔 I think short term has_one is the way to go then, as even if we wanted to add manual to belongs_to I don't think it would have the highest prio. Maybe zach can chime in on the if later. One thing to think about is that you could also just add those things you have in indexes as calculations as well and just use has_(one/many) with no_attributes and a filter that uses the calculation, that way you wouldn't need the manual relationship.

ZachDaniel•3mo ago

There shouuld be no functional difference between a manual belongs_to and a manual has_one

barnabasj•3mo ago

there is no manual belongs_to according to docs

ZachDaniel•3mo ago

Right What I mean is that there is no need for one

barnabasj•3mo ago

yeah, that's what I assumed.

mcollOP•3mo ago

@Zach Daniel there is a semantic one, but I can override the semantics myself I understand since it's a manual relationship it doesn't matter, but it was to more easily understand what is going on when you look at the code. at a glance if I see a belongs_to I will understand what we are doing is gathering another resource from a key that is in this resource. If I see a has_many or has_one I will assume the id of this resource is in another resource. I also need it to discriminate inside the manual relationship to know where to search for :field.

ZachDaniel•3mo ago

Yeah, I see what you're saying at the moment its not reasonable to change though ultimately

mcollOP•3mo ago

however I understand that since you cannot really know if thats the case, has_one and has_many are easier to reason about within manual relationships

ZachDaniel•3mo ago

too many places expect only has_ to be manual

mcollOP•3mo ago

gotcha

ZachDaniel•3mo ago

But feel free to open a proposal, I could see it being a value-add to have

Gaming

Programming

Manual relationship in belongs_to

Did you find this page helpful?