Fork me on GitHub

Hey guys, I'm trying to achieve something, but I can't seem to get it right. I'm writing a small application to store and edit forms using Om.Next and DatasScript. I'm running DataScript in the backend to store the forms. In the front-end, I'd like to display a list of form id's, and when one is clicked/selected, the corresponding form. My problem is that I can't seem to query both all form ID's and all the data from a single form using the same pull syntax. To get all the id's, I have to do something like (d/q '[:find ?id :where [_ :form/id ?id]) (d/db conn)), while to get all the fields from a single form, I have to do something like (d/pull (d/db conn) '[*] <eid>)


@linuss I think you can use a pull expression (d/q '[:find (pull ?id [*]) :where [_ :form/id ?id]) (d/db conn))


I'm afraid not: this results in the error "Expected number of lookup ref for entity id"


I can do (d/q '[:find (pull ?e [:form/id]) :where [?e :form/id]] (d/db conn)) though


But, by using this way of querying, I can't get all the fields from a single form


(d/q '[:find (pull ?e [:form/id]) :in $ ?id :where [?e :form/id ?id] (d/db conn) <your_form_id>) ?


Ah, yeah, that works! However, it doesn't really solve my problem. The thing is is that I'd like to use the queries of my Om.Next components directly in DataScript. This page seems to indicate that that should be possible without too much trouble, but I can't seem to figure it out in my case


In the solutions above, I keep having to supply a where clause for the single form


Well, you aren't far away from the :app/counter parser read method in that tutorial...


Just to warn you, doesn't really support datascript in my opinion (you'll have to live without set-query! anyway, which is quite difficult in any serious application). This isn't as clear as it should be in the documentation.


The queries don't translate 1to1 either, you'll always have some parser code like in that tutorial to transform basic pull patterns into a proper query.


Hm, okay. If it doesn't, then is there another way to persistently store data that works better with Om.Next?


Anyway, probably want to move back to #om for these kind of discussions...


Haha, I tried that first, they sent me here 🙂


The default store is just an (atom {}) and om does some normalization magic.


Yeah, that was me that sent you here 😛


Oh, haha, right