Good question…oversight?

My memory is a little vague, and I’m not looking at the code. The idea is this, though, and it may not be an oversight: The schema is the format of the database, but the design is such that you can shard data over many database instances based on the current request. Thus, the database name might be one of many, whereas the schema will be constant across all of them. The database selector function is picking a database for a schema based on env.

Ok so the schema is intended to be separate from the database name. I would think that the attributes would need to be saved in the development and staging databases as well. So perhaps main would be a better name for the schema

Yes of course

That's the oversight... Poor naming

... or use Calva which will do this for you automatically :-)

Well there are two levels of things: Things that are generic and defined in RAD itself, and others which a given rendering plugin might want to define for extended behavior. I’m not claiming perfection on anything, but the intention at least was to put the SUI-specific options under SUI-specific keys so they would not conflict with other possible plugins/interpretations.

For example the layout-class can be specified in both component-options and rendering-options: https://github.com/fulcrologic/fulcro-rad-semantic-ui/blob/f2d1841b5d2168e7aaad3f0a1e868c13313f5a07/src/main/com/fulcrologic/rad/rendering/semantic_ui/form.cljc#L378

Is it better for an option like that to be retrieved from both or from just the rendering options? Since all the options are fully qualified keywords I don't think there'd be a naming conflict either way. But it does add consistency to keep every option under the same key

I'm asking because I want to know what to prefer in the rendering plugin I'm creating

I'm perfectly fine with whatever makes sense for your use case. As long as the options are documented so people know where to put them, then I'm ok with it. You could expect them on the to level report or form if they make sense there, subforms, custom subtree...

I've honestly been hoping others would contribute and chime in. The existing stuff tried to set the patterns, but it is a lot of stuff to maintain, so it's hard to keep it all straight. Also, there are typically some legitimate variations that will make sense. I'd say make it, use it, but be slow to publish it so you have easy flexibility to rename

One thing I really like about rendering-options is the the set-global-rendering-options! function. I think it reduces duplication

Right, see, I forgot I even wrote that 😛

I have to go back and read my own books/code/notes all the time

lol

I have a large production project and it is pretty settled at that level, so I haven’t needed to use that in literally years,