Fork me on GitHub
#fulcro
<
2017-10-07
>
tony.kay02:10:05

New snapshot of semantic wrappers. Some of them were missing due to a bug in my generators. I ported the HomePageLayout using it on another project, and it works well.

myguidingstar02:10:53

@tony.kay I think you're right, that should have been about bidirectional graph . I'm familiar with SQL and Datascript/Datomic and not so with om.next's database. I don't even know the right way to do that in om.next and the representation for the books:left_right_arrow:authors example above is SQL-ish

myguidingstar02:10:05

let's say that's what I would do in my SQL database, then how should I design my fulcro/om.next db with least duplication?

tony.kay02:10:23

there will be no duplication. You just put your items in tables, and add edges. Nothing more to it

tony.kay02:10:19

{:TABLE {ID { item-props :edge [:OTHER-TABLE ID] }}
 :OTHER-TABLE {ID {item-props :edge [:TABLE ID]}}}

tony.kay02:10:06

SQL databases are not graphs…you get a table based on a join, so the join really has no direction

tony.kay02:10:23

in Datomic, you have graph support, and the edges are automatically bidirectional

tony.kay02:10:13

in Om Next, the edges are simple data, and have a direction…so you need to explicitly point in both directions IF you need to navigate in both…but then the question is: do you really need to navigate in both? If so, then you need both edges…perhaps this is what you’re calling duplication

tony.kay02:10:30

If the data is coming from a server, then you can also load the data in one direction with that use of it is on-screen, and re-load it with a diff query (in the other direction) later…that would end up building both edges; however, your mutations are still going to have to maintain the edges. One additional alternative: You can hack into the database query engine and implement your edge traversal (ala plain Om Next). Fulcro lets you do this selectively.

tony.kay02:10:44

(see the local reader option when creating a client)

tony.kay15:10:55

@rastandy custom types should work as opaque values, but not work as table entries queried and normalized with the query language and idents. The former are not manipulated, the latter are

tony.kay15:10:45

I know that defrecord is map compatible and should stay the correct type through assoc/dissoc, so it is probable that you could fix this by converting the any of the internal algs away from things like uses of into

tony.kay15:10:40

I'll look into adding a note to the docs

tony.kay15:10:55

Added to devguide section on app databases

rastandy16:10:36

@tony.kay thank you very much for the explanation. If needed I’ll dive in the merging algorithms to try to preserve records in the fulcro database. I would learn more for sure 🙂