This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # babashka (28)
- # beginners (68)
- # cider (12)
- # clj-kondo (5)
- # clojure (37)
- # clojure-spec (4)
- # core-async (5)
- # cursive (3)
- # data-science (1)
- # datomic (70)
- # fulcro (18)
- # graalvm (1)
- # joker (1)
- # luminus (2)
- # malli (11)
- # off-topic (21)
- # shadow-cljs (3)
- # spacemacs (11)
- # test-check (3)
- # vrac (8)
How would you describe an attribute in RAD which is represented by a composite of 2 columns in the database?
or even a normal one to many: for instance there’s a
user table with PK
id , and there’s a table
user-authority where there’s no PK, just
user-id which links the first table and some data… I don’t know what to specify as identity attribute for
I think each "table" should have an unique id, I use uuids myself just like the demo app.
Many existing databases don’t have an ID column in every table and if you ask any SQL purist, they really shouldn’t have an ID column if existing columns naturally present a key. Otherwise you are doubling your indexes e.g. you have index on ID, then a unique index on
service, email columns, since they are a natural PK in the table in question… the whole discussion is moot because I have to use existing data sources and as such this decision is not mine to make.
Btw in many-to-many linking tables, do you have a special ID for that too e.g.
id, foreign_id_1, foreign_id 2 ?
No afaik just making it a ref is enough, it is not like sql in that it creates a graph and traverses it, you do not need to specify the foreign key because the ref uses the entity id to join them.
This helped me understand what was happening: https://docs.datomic.com/on-prem/query.html
Everything is flattened to entity-attribute-value-time, so "tables" don't exist, and refs are just an attribute join on an entity id.
so when working with a legacy DB I guess the answer is to make tons and tons of custom resolvers that present existing data in this way…
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.
That's pretty much how you have to do it, in terms of foreign keys #pathom might be better to answer questions on specifics, I'm still pretty new to all this stuff, but I think it's pathom that requires an ident to be set to normalize the data.
I didn't use SQL but tied to a rest api and it took a significant number of resolvers to get everything into the format fulcro/pathom wanted.
For the rest api I only needed 1 resolver per ident to get it working, but had to create a bunch more resolvers to make things more efficient, since with just 1 resolver per ident it would query many times to get a single item that had what in SQL would be joins.
On the topic of joins… I tried to make attribute with
ao/pc-resolve use batching by adding `
to the attribute map, but the input I get is not sequential… are these keys supported on attributes?
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