@mitchelkuijpers well, interestingly:

(def db {:root [:k 1] 
         :k {1 [:k 2]
             2 {:x 1}}})

(om.next/db->tree [{:root [:x]}] db db)
; => {:root {:x 1}}

does seem to work.

and when I look at the algorithm it does seem to be recursive in it’s treatment of idents. I still would not do it, myself, though. Seems to convolute the database too much.

I’m confused as to why you’d need to do that

but now the question is: since Om Next supports it, should our forms support as well

In a form we have an default value which I only know when the data is loaded. Because the values are configurable

So I want so set a ident somewhere to fill the default value when it's loaded

And I noticed indeed that it works in Om

default value of what?

a field?

or an entire form

I don’t see why that case just isn’t a post-mutation that puts the data where it needs to be…not sure why an ident is involved, much less two of them

if it is a field, why not just have a post-mutation on the default load that puts it into the field iff it isn’t filled. Same with a sub-form: fill in the fields with the defaults.

Yes that is how I fixed it now

A subform for a field

But now I have to load it and put it in place in the form otherwise it would just be at that place to reference when it is loaded

@mitchelkuijpers you do have to put it in place, but I don’t understand why that would lead to ident -> ident -> value

nor why that needs to be a subform for a single field

Kind of hard to help without code