sof question

[Jozsef Hegedus]

Hi, 

I am not sure if this question is relevant here : http://stackoverflow.com/questions/41201045/normalized-and-immutable-data-model

What do you think ?

Regards

Jozsef

[A.M.]

Hi Jozef and welcome to the list!

Indeed, relational algebra does have something to say about this scenario.

Firstly, it is worth noting that determining a key, especially a
naturally-occurring, or "natural key", is often challenging. In this
case, a name makes a poor choice for a key because it is often easy to
find two people with the same name and, as you noted, names can change.

Barring the above objection, however, the relational algebra provides
for changing key values. However, the relational model cannot
distinguish between whether a key is changed because the object being
modeled has changed or because the object was removed and a new one added.

Why? It is due to relational assignment:

people := relation{tuple{name "Steve"}}

If I wish to append a user to the relation, I can use assignment:

people := people union relation {tuple{name "Bob"}}

This is equivalent to insert. An update of "Steve" to "Stephen" is
equivalent to:

people := (people where not (name = "Steve")) union (((people where
name="Steve") : {name2:="Stephen"}){name2} rename {name2 as name})

Given this assignment scheme, we see that the relations are indeed
immutable and we can follow that there is no way for the model to
extract additional meaning from the update. That's why SQL database
include additional schemes like "ON UPDATE CASCADE/DELETE". The
underlying model simply cannot know so let's the user choose.

The sample scala implementation is effectively identical to what the
answer by Yawar. In scala, we create references which are necessarily
unique to track the users, then the names are no longer keys. Similarly,
in Haskell, artificial unique identifiers are created alongside the
names. Note that the artificial/unnatural keys have no relationship to
the people and effectively model nothing in the real world. They are
"synthetic keys".

With regards to:
"..if I want to model a normalized SQL database in Haskell is there a
general way to describe foreign keys? By general I mean, not hand coding
the IDs as suggested by chepner in the comments below."

Project:M36 is not an SQL database, but it does otherwise fit your
criteria. The project uses immutable structure to represent the database
state which is typed as:

DatabaseContextExpr (insert, update, assign, etc.) -> TransactionGraph
-> TransactionGraph

The reason that the ProjectM36.Client module requires the IO monad is
because the database can be remote, but a pure, in-memory client would
also be possible. Project:M36 integrates very with Haskell and allows
for ADTs as database values- something which SQL databases will never do.

However, nothing about Project:M36 prevents one from making a relation
variable with a poor choice of keys.

Feel free to try out the examples above at https://try.project-m36.io/

Cheers,
M

[Elliot Cameron]

For some added perspective, Gabriel Gonzalez has discussed a way to interact with relational data like this in Haskell here: http://www.haskellforall.com/2014/12/a-very-general-api-for-relational-joins.html

--
You received this message because you are subscribed to the Google Groups "project-m36" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-m36+unsubscribe@googlegroups.com.
To post to this group, send email to proje...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/project-m36/13be3c1d-b0a2-047c-f045-7b17ab54f554%40themactionfaction.com.

For more options, visit https://groups.google.com/d/optout.

[A.M.]

On 02/22/2017 08:17 PM, Elliot Cameron wrote:
> For some added perspective, Gabriel Gonzalez has discussed a way to
> interact with relational data like this in Haskell
> here: http://www.haskellforall.com/2014/12/a-very-general-api-for-relational-joins.html

The main issue I have with that approach is that there is exactly one
key and keys must be instances of Ord. Though I understand why he does
this, there are no such requirements in the relational algebra.

Also, GG doesn't provide any examples of how the database state would be
altered, so I don't see, for example, how it would be possible to
represent constraints while maintaining the close binding to Haskell.

Still, it is nifty to see a lot of the relational algebra come alive
with so little Haskell code. I think it speaks to the mathematical
coherence of the relational algebra.

Cheers,
M

[Elliot Cameron]

That's a good point. I don't think he's necessarily promoting that approach as a genuine attempt at managing data in an application, but more as you noted the coherence of relational algebra and how well it fits into FP abstractions.

However, GG has a mysterious repo on GitHub that seems to be doing something more ambitious: https://github.com/Gabriel439/Haskell-Bears-Library

[A.M.]

On 02/22/2017 08:36 PM, Elliot Cameron wrote:
> That's a good point. I don't think he's necessarily promoting that
> approach as a genuine attempt at managing data in an application, but
> more as you noted the coherence of relational algebra and how well it
> fits into FP abstractions.
>
> However, GG has a mysterious repo on GitHub that seems to be doing
> something more
> ambitious: https://github.com/Gabriel439/Haskell-Bears-Library

Good find! This is similar in some ways to
https://github.com/andrewthad/vinyl-vectors

Based on the differences in the libraries, I strongly suspect that
Project:M36 should include support for:

* statically-defined compile-time relvar types which map directly to
Haskell types (to aid in pushing errors to compile time rather than runtime)
* generics support to convert Haskell ADTs to database values and back
(to easily marshal custom ADTs in and out of the database)

I have added the issues.

Cheers,
M

[Elliot Cameron]

​Hear hear!​

[Jozsef Hegedus]

Hi M,

Thanks for the detailed answer.

Is M36 used for something in production ?

Regards,

Jozsef

[A.M.]

On 02/23/2017 12:41 PM, Jozsef Hegedus wrote:
> Hi M,
>
> Thanks for the detailed answer.
>
> Is M36 used for something in production ?

Project:M36 is very young and setting out to prove that mathematical
correctness is not to be compromised. In accordance with this goal, the
implementation does not focus on performance which make the project not
suitable for all database deployments.

However, we have good code test coverage, remote API access, as well as
client bindings to JavaScript and Haskell, so we are working towards
making the project as useful as possible.

Currently, the biggest deployment of Project:M36 is at
https://try.project-m36.io/ thanks to 3noch.

We hope that you will join us!

Cheers,
M

[Elliot Cameron]

I'm very eager to use Project:M36 in some upcoming projects. At this point Project:M36 is probably best suited for projects that don't have tight deadlines or tight performance requirements. I plan to use it as the DB backend for a simple web app with live-updating components (via websockets). Project:M36's native support for websockets is pretty cool and I hope to have my web pages connect directly to the database for that part. I don't expect my user base to grow very fast, so I'm not worried about the deadlines or performance.

Cheers,
M

--
You received this message because you are subscribed to the Google Groups "project-m36" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-m36+unsubscribe@googlegroups.com.
To post to this group, send email to proje...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/project-m36/c9e9aac5-f70a-8ace-ef36-b8a8afb86f6a%40themactionfaction.com.

[Jozsef Hegedus]

Thanks for the info M,

I asked the SOF question because I was looking for something like M36 for Scala for a little web-app I am building.

Regards,

Jozsef