fulcro 2024-03-02 | Slack Archive

genekim04:03:44

@pt.roterski Thank you for writing the XTDB RAD plugin — I’ve been using it for a bunch of projects, but I’m a little fuzzy on some of the implementation details. I’m wondering if you can shed some light, as I think I am misunderstanding something, which is biting me or causing some considerable confusion. If I understand correctly, :xt/id must be unique, as it is the only thing is used for entity identify — in other words, it is the “E” in “EAV.” In Section 2.2 in the In RAD book, Tony writes: > Each type of entity/table/document in your database will need a primary key. Each attribute that you define that acts as a primary key will serve as a way to contextually find attributes that indicate they can be found via that key. This is very similar to what you’re used to in typical databases where a primary key gives you, say, a row. RAD’s data model does not constrain an attribute to live in just one place, as you’ll see in a moment. > > The ao/identity? boolean marker on an attribute marks it as a “primary key” (really that it is a key by which a distinct entity/row/document can be found). Let’s suppose I have a podcast-attribute model, which has a podcast-episode/id attribute, defined such as:

(defattr id :photo/id :uuid
  {ao/identity? true
   ao/schema    :photos})

``` What relationship does the :photo/id have with the xt/id ? • At one point, I thought that :photo/id did not need to be defined, as it was copied from st/id. (I’ve determined this not to be correct.) • Then I manually started setting :photo/id to xt/id, which worked fine… • But then I found a form wouldn’t load, because :photo/id didn’t match the xt/id. Although this was surprising to find, that the form broke because this condition wasn’t true was unsettling, because I didn’t realize that the two HAD TO EQUAL? Could you shed some light on what the relationship between :photo/id and xt/id should be? Thank you!!

Piotr Roterski05:03:34

Hey Gene! First of all, thanks for the kind words - I wasn't aware that anyone was still using this plugin, and I abandoned it myself so the plugin might be not up to date with fulcro-rad and my knowledge of it is a bit rusty. Regarding your question, AFAIR the assumption is that :entity/id (or :photo/id etc.) needs to be equal to :xt/id , :entity/id comes from fulcro-rad requirements for table's primary-key and :xt/id is https://v1-docs.xtdb.com/language-reference/datalog-transactions/#document to be present on every document - so even at cost of duplication, the idea was to maintain the same values for them. I just peeked with REPL into https://github.com/roterski/fulcro-rad-xtdb/blob/main/src/main/roterski/fulcro/rad/database_adapters/xtdb/wrap_xtdb_save.clj#L124 sent in fulcro-rad-demo - see the attached screenshot where :xt/id has the same value as :invoice/id (and delta map's top key). You can see this assumption in https://github.com/roterski/fulcro-rad-xtdb/blob/main/src/main/roterski/fulcro/rad/database_adapters/xtdb/wrap_xtdb_save.clj#L112-L113 as well. If that assumption is not held, it's most likely a bug. I was under impression, that you don't really need to set :xt/id manually as it was more of an implementational detail of the plugin (inherited from xtdb) and with fulcro-rad you would operate on this primary-key (eg. :invoice/id) - but I'm not sure how much you could rely on it because it's probably not enforced enough.

Piotr Roterski05:03:25

if anything in this logic: > I thought that :photo/id did not need to be defined, as it was copied from xt/id. could be fixed, it should work the other way, :xt/id is copied from :photo/id

genekim06:03:41

This is so helpful! I will respond more fully tomorrow — I can’t wait to look at this again when I have a clearer head. I’ll keep you posted! 🙏 🎉

🙏 1

genekim18:03:21

Thank you for the fantastic and complete (and such a fast) answer last night. It was everything I needed to know. My problem was that in one record, I accidentally created in a document two entity ids: :podcast/id and :podcast-episode/id. Your RAD plugin continues to work fabulously — I will put in a PR for some additional notes that I’d love to have in the README. (And thanks for writing it!)

🙏 1

Piotr Roterski05:03:38

I'm glad I could help and feel free to submit PRs! :)

Eric Dvorsak09:03:52

I am doing a dropdown that loads the data and expands on click, I used hooks/use-state for expand, on df/load/`set-expand true` on click, but as soon as the data loads expand resets to true. I'm assuming it's because the components rerenders because its props changed, I wasn't expecting useState to keep the state of expand was that a wrong assumption or it's something else in my code?

tony.kay16:03:08

React should only reset if you unmount and remount the component. One way that could happen is if the react key changes. So my first guess is that you are loading the component, it's ident changes, the key function of the factory changes the key, and so the component remounts

Eric Dvorsak16:03:03

Yeah I dont have an ident at all on that component

Eric Dvorsak17:03:10

ok actually I did add a keyfn and forgot about it, removing it fixes the issue. Pretty sure I'm doing something wrong to begin with but at least it works now

2024-03-02

Channels