Singleton resources

Singleton being defined as: "There is only ever one, no more and no less." Is there a recommended pattern? So far I have something that is basically anAsh.Resource with create, read and update actions and: - Does not allow anybody to call create, and does not expose it via frontend channels; - Automatically populates the record if it does not exist with the bare create using authorize?: false; - Automatically fetches the single record using in update. This is somewhat less than ideal. Would there be interest in supporting something like this more explicitly? The primary difference in behaviour to other resource types are: - They cannot be created or destroyed. - They can only be read or updated. - It is unnecessary to pass an instance of them to update actions. - There is no sense in filtering them (but still sense in determining which attributes to select). Otherwise, many of the same things that make sense for other types of resources make sense for singletons as well, and there are a fair number of situations where the thing that best describes my domain is a singleton.
4 Replies
ZachDaniel
ZachDaniel3y ago
It sounds interesting 🙂 once we have support for “bulk update” actions, that would support the “no need to pass an instance to update” issue, because you’d say “update all of them” and there’d only be the one. It sounds interesting, potentially as an extension that helps with some of these conventions (maybe sets all read actions to get? true implying they only return a single thing, and marking all fields as not filterable, that kind of thing.) Would need to explore, maybe just starting simple.
\ ឵឵឵
\ ឵឵឵OP3y ago
Is your plan for exposing the bulk updates (especially via GraphQL) to have them take a similar filter to a list operation as well as a set of attributes/relationships to update, or to have it simply take an array of items to update individually which each include PK?
ZachDaniel
ZachDaniel3y ago
Either/both 🙂 I’ll have to take a closer look at the ergonomics once it’s time. But that’s what it will look like for bulk actions in code yes. List of inputs or queries.
\ ឵឵឵
\ ឵឵឵OP3y ago
Right on, since that's on deck already, can revisit once it's out. The usual interface for these things is really simple, essentially:
> Singleton.get!
%Singleton{a: nil, b: 1, c: "stuff"}
> Singleton.set! %{a: 2, b: 3}
%Singleton{a: 2, b: 3, c: "stuff"}
> Singleton.get!
%Singleton{a: nil, b: 1, c: "stuff"}
> Singleton.set! %{a: 2, b: 3}
%Singleton{a: 2, b: 3, c: "stuff"}
Naturally, the beauty is making that play well with the rest of the ecosystem.

Did you find this page helpful?