Re: [elm-discuss] Re: Metalinguistic abstractions over databases

Okay awesome. Thanks so much! On Fri, Nov 4, 2016 at 7:54 PM, OvermindDL1 wrote: > Ah, no, in fact I do not recall seeing that, it looks like it has had a > lot of development recently so it appears that it might be newer than when > I built my api pipeline. I've not had

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Wednesday, November 2, 2016 at 4:50:21 AM UTC-5, Rupert Smith wrote: > > On Tuesday, November 1, 2016 at 5:54:10 PM UTC, Kasey Speakman wrote: >> >> In a new project, we are going for something like this. >> >> >> https://www.youtube.com/watch?v=GneIxgl71NM=18=PL9Z-JgiTsOYTdi91N_DlcpWqkCYvMrhA4

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tuesday, November 1, 2016 at 3:31:07 AM UTC-5, Peter Damoc wrote: > > On Tue, Nov 1, 2016 at 2:25 AM, Kasey Speakman > wrote: >> >> So here's a concrete example of how we did it wrong in our legacy system. >> To close a trainee's registration as "No Show", an employee

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tuesday, November 1, 2016 at 1:16:40 PM UTC, Kasey Speakman wrote: > > > http://blog.ploeh.dk/2013/12/03/layers-onions-ports-adapters-its-all-the-same/ > I agree with this. I was very happy to see in the first couple of paragraphs a description of what usually goes wrong in OO implementations

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tuesday, November 1, 2016 at 5:54:10 PM UTC, Kasey Speakman wrote: > > In a new project, we are going for something like this. > > > https://www.youtube.com/watch?v=GneIxgl71NM=18=PL9Z-JgiTsOYTdi91N_DlcpWqkCYvMrhA4 > What sort of throughput in events/sec are you aiming to support? -- You

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

Just wanted to say, thanks for posting this Kasey. It's great to hear the nasty details, though I'm sure it's not so great to live with them day to day :) It's a great point about implicit behavior pushing off programming from the system onto the users. Thanks also for the links. I have been

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

In a new project, we are going for something like this. https://www.youtube.com/watch?v=GneIxgl71NM=18=PL9Z-JgiTsOYTdi91N_DlcpWqkCYvMrhA4 On Tuesday, November 1, 2016 at 10:00:36 AM UTC-5, Kasey Speakman wrote: > > On Tuesday, November 1, 2016 at 9:53:55 AM UTC-5, Rupert Smith wrote: >> >> ...

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tuesday, November 1, 2016 at 2:10:05 PM UTC, Peter Damoc wrote: > > It would be awesome to have a more complex but practical example that > captures this. > > The reservation scenario from the second post looks like an interesting > use-case. > > I will think more about it. > > > On Tue,

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tuesday, November 1, 2016 at 9:53:55 AM UTC-5, Rupert Smith wrote: > > ... > There is clever stuff we can do with the data-centric approach, in terms > of using generic CRUD APIs, or tailoring graphql expressions to fetch or > update particular paths in the data model. It is a bit harder to

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tuesday, November 1, 2016 at 9:36:36 AM UTC-5, Rupert Smith wrote: > On Tuesday, November 1, 2016 at 1:16:40 PM UTC, Kasey Speakman wrote: >> >> It is silly, and I don't know why it was done this way. But that's the >> world I live in now. It's easy to justify one case at a time, but all >>

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tuesday, November 1, 2016 at 1:16:40 PM UTC, Kasey Speakman wrote: > > It is silly, and I don't know why it was done this way. But that's the > world I live in now. It's easy to justify one case at a time, but all > tolled it adds up. > > As far as "layers", you should check out these two

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

It would be awesome to have a more complex but practical example that captures this. The reservation scenario from the second post looks like an interesting use-case. I will think more about it. On Tue, Nov 1, 2016 at 3:33 PM, Kasey Speakman wrote: > Oh, and yes, most

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

Oh, and yes, most of these layers are on the server side if we are talking about an Elm client application. Generally speaking, the client app serves to collect and prepare data to submit use cases. So it reads data from an API and submits data to an API. On Tuesday, November 1, 2016 at

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

It is silly, and I don't know why it was done this way. But that's the world I live in now. It's easy to justify one case at a time, but all tolled it adds up. As far as "layers", you should check out these two posts in order.

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tuesday, November 1, 2016 at 10:00:08 AM UTC, Peter Damoc wrote: > > On Tue, Nov 1, 2016 at 11:30 AM, 'Rupert Smith' via Elm Discuss < > elm-d...@googlegroups.com > wrote: > >> Are you talking Elm running server side for this? >> >> I haven't thought about that too much. > In theory, there

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tue, Nov 1, 2016 at 11:30 AM, 'Rupert Smith' via Elm Discuss < elm-discuss@googlegroups.com> wrote: > Are you talking Elm running server side for this? > > I haven't thought about that too much. In theory, there should be some kind of schema common to both the front-end and the back end that

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tuesday, November 1, 2016 at 8:31:07 AM UTC, Peter Damoc wrote: > > However, looking at a fresh system that one might want to design it seams > to me like there are 3 possible layers > > Layer 3. Business Objects Layer - concerned with validity of state > transactions > Layer 2. Data

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tue, Nov 1, 2016 at 2:25 AM, Kasey Speakman wrote: > > So here's a concrete example of how we did it wrong in our legacy system. > To close a trainee's registration as "No Show", an employee has to create > an exam against that registration and grade it as 1%. This is an

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

> > "Explicit is better than implicit." -- Tim Peters So the main way "data-centric" happens is by modeling behaviors implicitly in the data. A common example is an item being active or not. I often model this as a boolean property "isActive". The usual way to tweak this value is to have

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Friday, October 28, 2016 at 4:58:34 PM UTC-5, Rupert Smith wrote: > > On Friday, October 28, 2016 at 6:26:46 PM UTC+1, Kasey Speakman wrote: >> >> As best I can, I try to look at the system as use cases and events. >> >> With legacy systems, we are tied to a normalized data model (which is

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Mon, Oct 31, 2016 at 5:24 PM, Kasey Speakman wrote: > There is a danger in focusing on data over use cases. It's not a guarantee > that you make this mistake (I have), but you know you've gone too far with > it when most workflows are Load/Edit/Save (or Create/Save). And

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

There is a danger in focusing on data over use cases. It's not a guarantee that you make this mistake (I have), but you know you've gone too far with it when most workflows are Load/Edit/Save (or Create/Save). And the user is left to know what field to change to have a specific effect in the

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Friday, October 28, 2016 at 10:58:34 PM UTC+1, Rupert Smith wrote: > > For example, if a user account must have an email address associated with > it, if there is validation on the format of the email address and it cannot > be null, then there is not need to write a specific transactional

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Friday, October 28, 2016 at 6:26:46 PM UTC+1, Kasey Speakman wrote: > > As best I can, I try to look at the system as use cases and events. > > With legacy systems, we are tied to a normalized data model (which is > really designed for writing and not reading), so for queries we have to >

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

As best I can, I try to look at the system as use cases and events. With legacy systems, we are tied to a normalized data model (which is really designed for writing and not reading), so for queries we have to "project" from that normalized data model into another model. But the place I'd

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tuesday, October 25, 2016 at 3:12:53 PM UTC+1, Kasey Speakman wrote: > > So to phrase what I previously said a different way, a database is the > wrong level of abstraction to be shooting for. > Yes, I think you are right. Much better if we can just think about the data model we need, and

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

So to phrase what I previously said a different way, a database is the wrong level of abstraction to be shooting for. A database is just one integration that most business systems have. The system itself exposes use cases and queries. Whether and which databases are involved (and their

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tuesday, October 25, 2016 at 10:01:48 AM UTC+1, Peter Damoc wrote: > > On Tue, Oct 25, 2016 at 11:27 AM, 'Rupert Smith' via Elm Discuss < > elm-d...@googlegroups.com > wrote: > >> If your 'persistence API' requires the application to behave correctly in >> order to not store invalid or

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tue, Oct 25, 2016 at 11:27 AM, 'Rupert Smith' via Elm Discuss < elm-discuss@googlegroups.com> wrote: > If your 'persistence API' requires the application to behave correctly in > order to not store invalid or maliciously altered data, you cannot > guarantee that. > This actually sounds more

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tuesday, October 25, 2016 at 9:27:58 AM UTC+1, Rupert Smith wrote: > > On Tuesday, October 25, 2016 at 8:08:11 AM UTC+1, Peter Damoc wrote: >> >> Browsers can provide a trusted environment through the use of https. This >> is what Gmail and Facebook and all other webapps are doing. >> > >

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tuesday, October 25, 2016 at 8:08:11 AM UTC+1, Peter Damoc wrote: > > Why not just freeze dry your entire application state to some key/value >> store (on every update), then you have a simple way to rehydrate the whole >> application after a period of inactivity? >> > > This is not an option

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tuesday, October 25, 2016 at 8:08:11 AM UTC+1, Peter Damoc wrote: > > Browsers can provide a trusted environment through the use of https. This > is what Gmail and Facebook and all other webapps are doing. > What I mean is, there is nothing to stop whoever is running your application from

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tue, Oct 25, 2016 at 2:06 AM, 'Rupert Smith' via Elm Discuss < elm-discuss@googlegroups.com> wrote: > I think the model that has the lowest 'cognitive overload' for a beginner > is to simply work with the request/response model of HTTP, and to request > data when needed, and POST data when you

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Monday, October 24, 2016 at 1:15:14 PM UTC-7, Peter Damoc wrote: > > Think about the role that a ORM is playing. What I want to understand is > what would a functional equivalent would look like in Elm. > > What would sit above graphQL or REST or some other lower level tech? > > Another way

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

I cannot provide sample code because I don't have a clear idea how the API could look. Think about the role that a ORM is playing. What I want to understand is what would a functional equivalent would look like in Elm. What would sit above graphQL or REST or some other lower level tech? Another

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Monday, October 24, 2016 at 8:33:55 AM UTC-7, Peter Damoc wrote: > > I'm more interested in how one would solve this in a multilayer system > where the actual remote persistence is abstracted from the app. > > The actual remote persistence might be implemented with REST, or it might > be

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

What I'm looking here is more like a strategy that takes into account the entire persistence layer from the perspective of an Elm Architecture app. If one doesn't need to store data remotely, one could simply either use just some transient model OR, use something like localstorage to persist some

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Monday, October 24, 2016 at 1:17:30 AM UTC+1, John Kelly wrote: > > I'm coming to the sad realization that an api like this is simply not > possible: > > ``` > session = > resource "sessions" > { id = int "id" > , speaker_id = int "speaker_id" > , start_time =

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

> > My issue is in fact related to mutually recursive types, it's just that my > types are truly infinite. According to the linked doc about recursive types: > "Somewhere in that cycle, you need to define an actual type to end the > infinite expansion." Which mine does not. That's just what I

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

To my knowledge, the recursive type that you specified *will* compile. See here . My issue is in fact related to mutually recursive types, it's just that my types are truly

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

I guess you weren't explicitly defining type aliases for those records. But still, I think you might be able to salvage the API if you wrap the records in union type constructors. On Sun, Oct 23, 2016 at 6:10 PM, Nick H wrote: > If you are trying to make a recursive

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

If you are trying to make a recursive type definition, you need to use union types. E.G. This is not OK: type alias Session = { speaker : Speaker } type alias Speaker = { sessions : List Session } But this will compile. type Session = Session { speaker : Speaker } type Speaker = Speaker {

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

I'm coming to the sad realization that an api like this is simply not possible: ``` session = resource "sessions" { id = int "id" , speaker_id = int "speaker_id" , start_time = string "start_time" , end_time = string "end_time" , location = string

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

Just to follow up on the limitations in my library I spoke about -- namely, not being able to represent the relationships *in *the resource definition. I spent a bit of time drafting up some potential api changes that would make it possible: here

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

Great Question! You can checkout an example here . It builds off of the example presented in the docs. Currently, the library does not support representing relationships in the Resource definition, however, the library

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

Hi John, The project you linked to looks great. How do you deal with references? (entities referencing other entities) On Thu, Oct 20, 2016 at 9:19 PM, John Kelly wrote: > I'm sorry to link drop, but I've been doing a bit of work on a library to > remove some of the