Clojurians Log v2

That worked, thank you 🙂

Oh interesting, thanks for the link. I did #2, but then the column header was missing from the table. So I added an attribute for the reverse link, but then I made the mistake of linking it to the database schema, and couldn’t figure out how to skip the autogeneration of the schema for that attribute. I realized I needed to remove the ao/schema attribute. Now the report is working and I’m attempting to get a to-many control in the form editor to work.

I finally got it to work! I wound up needing to intercept the delta and rewrite it to change the owning side of the to-many references. https://github.com/thosmos/riverdb/blob/db4567b7eb957d9ee668525c8f48133421dd53e2/src/rad/riverdb/rad/middleware.cljc#L92

I wasn’t able to get the pathom attr resolver approach working like your example, but i already had that part working anyway. However, my approach for the resolvers would not work for the stock RAD setup because I use my own attribute specs to autogenerate my resolvers.

Yes, exactly.

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.

hey @holyjak, thanks a lot. I found out the multi-root examples on the main repo and I think that is the right way to go