Issues using Ash.Type.Union
So I'm trying to use Ash.Type.Union and I keep getting errors when attempting to load the resource,
I have defined an embedded resource
22 Replies
the parent resource has this data in the attribute which is a union type
and the parent resource attribute is defined as such
I get this error when tryig to load
Am I doing something obviously wrong or?
cast_input works
how did you save the data using ash or are you trying to load existing data from the database? Ash persists the data wraped inside union type like so:
so if you're trying to load existing data that's just the json, that won't work because it expects the format from above
ah right
yeah I'm trying to load existing data π
which is just json
hmmm :thinkies:
In that case you probably have to migrate it first, into a different column or something, load it as map, and persist it as ash union
that sounds like a lot of work
why does ash choose to save stuff that way tbh?
I would have thought just plain would be enough
not sure, tbh. have to wait for zach to answer that π
performs the ritual to summon zach daniel
leinad hcaz, leinad hcaz, leinad hcaz
Depending on how much data you have you could just do something like this for the migration
only a few million rows
π
could do it with a db query
I guess I'll migrate the data for now into Ash's format
I dont necessarily like it, but it may be for a good reason
maybe Zach can enlighten me as to why it was chosen to be saved like that, as opposed to just raw json with the type tag not being made into an attribute, or why the type tag wasn't able to be on the resource containing the union type (probably easier and more portable to have it tied to the type)
when you say this, do you mean type is the configured type tag?
i.e: for me it would be {"__schema": "call", "value": {...}}
I think it is the key for you type, which is the same in your case
But unions have been more trial and error for me than really understanding so far tbh π
yeah it's type
works

mmm I don't know if I like this π , it feels like 'application level' stuff starting to dictate how I do my database
at least it's just a type tag, it would be terrible if it was saving the actual module name of my type π€£
thanks @barnabasj π
We can make this configurable potentially π
The main reason is that you canβt always tell what type something is when loading from the database.
Like a value may be valid for multiple types
But when saving, we selected one.
It would be as easy as adding a constraint to the type TBH
personally I would like something that either has the type in the actual json - or something with the type tag on the resource, so in my case I can say this is transaction data for a 'email' transaction or a 'call' transaction
and the type can just be a FK to the transactions table
and if it's in the json, I would just something like this in json
Yeah, that makes sense, but only for some unions
i.e a union of only objects it works
yeah hadn't thought of the others π
But still, we could make these storage options a constraint with little-to-no hassle π
Can you make a GH issue describing the behavior youβd want to get out of your unions? Changing the underlying storage of unions is easy.
it would be opt-in right?
just because unions are already out in the wild
GitHub
configurable storage for union type Β· Issue #694 Β· ash-project/ash
Following on from our conversations on Discord, it would be helpful to be able to configure a simpler storage type for the union type. Ideally we would just store the json directly in the database ...
there we go
Yep! It would be opt-in π