On Friday, January 27, 2017 at 4:00:17 PM UTC, Peter Damoc wrote: > > On Fri, Jan 27, 2017 at 4:51 PM, 'Rupert Smith' via Elm Discuss < > [email protected] <javascript:>> wrote: > >> On Friday, January 27, 2017 at 10:15:49 AM UTC, Rupert Smith wrote: >>> >>> I think what is missing is DB access. >>> >> >> What would be even cooler is if you didn't need to worry about the >> database. If there was a way of declaring a Model in Elm, and every time >> you make an update to it, it automatically gets saved to the database, no >> need invoke a port to save it. I've always though a language which has >> persistence built in would be really cool. It could be done with Elm using >> the same trick as the time travelling debugger - just spool all the updates >> to disk and they form an 'event source' to recover the state from in the >> event of a crash. Occasionally you would check-point the entire state model >> to disk to make a fast recovery point. >> >> Well... this is what I'm looking into right now. Nobody wants to write > boilerplate. :) > > The idea would be for the page to interact with a client-side database > like entity that would take care of all the communication with the server. > > This is a complex topic. For example, I still have no idea how could one > express relational data in Elm? > e.g. Users have Messages and Messages have other Messages as replies and > each of those Messages have Users. How would you model that in Elm? >
I just take a 'slice' of relational data on the client, the slicing having already been done by the server API. So if I took a slice from Users -> Messages -> Users I may end up with duplicate Users on the client - but thats ok. In other words I expand relational models out into document models, each of which is a slice of the relational data. If I do want to represent a relationship on the Client, then I build a List or Set or Dict and populate it with data from various other slices. If I can see that a relationship being built on the client is already formed on the server side, I might just move it there as fetching it in one go will be more efficient. Provided it is something that makes sense as part of the API. For example, at the moment I have a database for 'content'. Each 'content' can be the parent of another. And a 'content' can also act as a container and contain child pieces that make it up. I have queries for fetching the table of contents as a tree, and for fetching a full container of content to render a page. Both these are document models extracted from the relational model on the server. > > I started a topic back in October but I haven't followed it through and > now it has almost completely vanished from my mind. > I'll go again through that discussion and think some more on this. > Yes, I remember it. I don't want to make the database directly accessed on the client though, as business logic on the client could potentially be bypassed, and the API to the database used to make direct modifications to the data. There may be complex or security rules that a server needs to enforce. This kind of automatic persistence has a lot more appeal to me as a server-side concept. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
