Clojurians Log v2
fulcro
That worked, thank you 🙂
I’m brainstorming how to add support for heterogenous lists to Fulcro RAD Datomic
for example, for a feed, which can contain videos, posts, images, etc. (similar to this Pathom docs example https://blog.wsscode.com/pathom/v2/pathom/2.2.0/connect/resolvers.html#_union_queries )
We could add an ao/targets which specifies the various qualified keywords representing the idents of the items
I think save-form will “just work”, but not sure how to generate the pull query here, of if thats possible with pull.
One idea I had was required a shared lookup ref across all of the items that could be stored, and could be used in place of the typical ident keyword. Alternatively, could look into re-writing the query using standard datalog.
Anyone else have thoughts / ideas / concerns?
perhaps one way to avoid this is to not generate resolvers for heterogenous lists by default, and require the user to write the query themselves?
Also think about SQL...
So you essentially want a "union attribute", right? What you propose sound reasonable.
For sql we would need some details (table, schema,..) for each of the possible types. Not sure how we would encode this in the DB so that it work with sql well...
I guess I'd need 2 columns in the "list", one with id and the other with type to left join TYPE1 t1 on list.id=t1.id and t1.type = 'type1' (well, the type column isn't strictly necessary, just a (premature :)) performance optimization...
yeah SQL would be quite complicated… but this could be a feature that only makes sense on backends that support it natively (like datomic)
right, so if you want to build a driver-specific feature, add a driver-specific option that gets added to the attribute. The problem with this particular idea is that it affects UI generation AND resolver gen. So, the UI plugin will have to understand it as well. So, on the SQL front (or any database for that matter) you can certainly find ways of modelling the resolution, and having users hand-write a resolver is par for the course. Auto-generation is a pure convenience. So, it might make more sense for us to just properly define union support at the generic model layer, and then drivers can choose to support it or not. The user can always write a resolver, so if the UI understands it, then all is well I think.