Clojurians Log v2

This is correct. The design of RAD is to be DB agnostic, and to represent things as facts that can be found from some source ID. I agree that this is not storage-ideal in some cases. The SQL adapter should be considered a prototype, and is not production ready. You can add addl keys to an attribute to describe how things “should work” for a given attribute, and that could include your own invention for how you might want to model things; however, form-state in fulcro is used for saves, and a given form does have to have something that can represent the ID in an ident. So, if you want to invent composite columns as an ID, you still need to resolve that composite as a single thing, even if it is the string concat of the other things.

Two answers: You can always write a raw pathom resolver for anything. The RAD attribute describes it to RAD…so you can have both. Attributes are just maps. The auto-generator looks for the ::pc/resolve key in order to select which things to include in the list of generated resolvers. Would accept a PR if you think other keys should trigger that. See resolvers.cljc

@tony.kay please check - https://github.com/fulcrologic/fulcro-rad-semantic-ui/pull/7

It is just one commit, however I merged your repo into my fork, and it pulled in all the commits since. So those are also appearing in the pull request.

kind of a mess with a broken merge in it

You’re going to need to clean that up

ok let me try

also, not sure I agree with what you’re trying to do. You can certainly make your own reporting code (copy what I have into your own file) and augment it with whatever features you want and “plug that in” to just your app. Things like “adding action” to an input does not sound right to me, changing implementations of things like decimal field…This PR sort of has a bit too much in terms of “under-designed feature creep and possible breaking changes” for me to be comfortable with it.

I get that you might want to tune buttons to have icons, but perhaps thinking through a wider scope of how to do that is part of the reason I have not done it yet. I don’t want a system that has a “sea of options” where a lake would do 🙂

also, a particular plugin (SUI) might use an icon class name, but mobile rendering might need something else. The options at that level might need to be namespacesd to the plugin to make that clear.

I have been doing that only till now, but that results in lot of code duplication, currently I have the whole code duplicated in so many places and want to get away from that.

I’m all up for help, I’m just saying I’m not as open to arbitrary design decisions happening through that help

I’m being purposeful in how slow it is changing, because once you release something that is mis-designed it’s a pain to fix. Whereas, RAD is designed to be user-augmentable, so there is current a “workaround” for these kinds of tweaks

also the form action buttons do allow a class to be specified, so I thought this would make the row action buttons consistent with them.

yeah, it’s possible it’s fine. The other thing we’re dealing with is that I have negative time right now

so, reviewing even a small PR like this is something I can barely afford

This discussion is even over my time limit, sad to say…but I’m doing it because I don’t want you to feel overly discouraged…just want you to know I’m super busy and really don’t have the time

yup and sorry for the broken merge, for some reason it was not showing up on my editor. no worries I will use my fork for now, and u can review it when u have time

your suggestions might actually be spot-on

appreciate your responses !

sure, thanks for trying to contribute!

What can you do when you get this in JS console: timbre_support.cljs:80 ERROR [com.fulcrologic.rad.ids:65] - Unsupported ID type :string I have entities that don’t have numerical or UUID IDs…

it looks like the three supported types are UUIDs, longs, and ints https://github.com/fulcrologic/fulcro-rad/blob/develop/src/main/com/fulcrologic/rad/ids.cljc#L56 I think you'll need to patch the RAD library if you want something else

You can: 1. fork the db adapter and add support 2. Add an ID column/attribute to the table/entity

I have nothing against alternate ID support, or even multi-column keys. I just don’t personally need it yet, and I’m very busy. RAD is extensible… extend it 😄

I use RAD in the context of “new project that needs to be stood up”, where you have control over db schema, etc. It’s a startup accelerator to me. I’m (personally) not at all interested in legacy integration (not opposed to it, either)

so, contributions are welcome to solve cases that make sense…wider database support, including these kinds of cases, is very welcome, but do not expect me to do it unless I’m getting paid to do so (or need it myself). I’m beyond capacity, unfortunately.