~euandreh

https://euandre.org

~euandreh/public-inbox

Last active 18 days ago

~euandreh/mediator

Last active a month ago

~euandreh/songbooks

Last active 2 months ago

~euandreh/test

Last active 2 months ago
View more

Recent activity

Re: crate2nix 18 days ago

From EuAndreh to ~euandreh/public-inbox

andi@notmuch.email writes:

> Hi,

Hi there!

> Just saw your crate2nix code and it looks very nice and clean!

☺️

> Just a heads-up, since you might not aware of all the alternatives out
> there, there is a version from Eelco that basically does the same as
> yours but also handles git dependencies. I did blog about that briefly
> last month [1].

Re: The database I wish I had a month ago

From EuAndreh to ~euandreh/public-inbox

I see what to mean by being accessible, and it does make sense.

If done properly this might be the reality, where nobody chooses to
handle conflicts manually because they'd rather have a consistent view
by picking one of the possible algorithms that are available for them to
pick for each attribute. I'll experiment with this a bit, and if 
feasible, the "perpetual inconsistency" might be an internal view, and
something available for those who choose to customize their conflict
resolution strategy. This would be ideal, and perfectly aligned with
what you said on "the application educating the storage layer about how
to handle most of the conflicts it encouters". The unique URL you showed
is a tempting challenge to reach, and the domain identity being
teachable sounds indeed really powerful.

Re: The database I wish I had a month ago

From EuAndreh to ~euandreh/public-inbox

> The obvious problem of always favouring the local timeline is that each
> timeline would show different "primary" answers, but that's sounds
> somewhat reasonable to me to enable the database to keep working while
> offline, and while the conflict isn't resolved.

Also a possible ergonomics layer that can be built on top of some lower level
primitive:

Suppose we want to add a profile page to an app, but the user will be
able to edit their profile while offline.

Such profile page contains 3 parts: name, bio and links. Here's how it
could look like:

Re: The database I wish I had a month ago

From EuAndreh to ~euandreh/public-inbox

Here's what I was referring to when talking about "durable persistent
data structures": https://www.youtube.com/watch?v=Cym4TZwTCNU

Re: The database I wish I had a month ago

From EuAndreh to ~euandreh/public-inbox

I better get a POC so I can stop talking in "what ifs".

I was more focused on the storage implementation side of it, but I'm
considering not implementing a storage backend for this and just using
SQLite instead (more detailed in [0]).

Building durable persistent data structures on top of SQLite backed
storage is still a bit distant, but the model I presented could benefit
from a POC.

I'll try starting that instead of giving so much focus on storage, and
share it later.

[0]: https://euandre.org/2020/08/31/the-database-i-wish-i-had.html#fn:posix-sqlite

Re: The database I wish I had a month ago

From EuAndreh to ~euandreh/public-inbox

I started quoting many parts of your email, and things started to get
confusing. Each answer that I gave was referring to each other, and I
almost made a loop.

So I've rewritten everything as a single piece of prose. I added some
snippets of your text to better contextualize what I was talking about,
but I tried to address what you said directly. Here it goes.

# On migrations

I still don't think that I've insisted enough on *strict* schema growth.

The wiki page you pointed to reinforces that: it talks a lot about how
to coordinate attributes that changed their names, change in vocabulary,

Re: building MSTs->CRDTs-> Re: The database I wish I had a month ago

From EuAndreh to ~euandreh/public-inbox

Jeff Rhyason <jeff@rhyason.org> writes:

> It's amazing to see this discussion. Let's keep it going!
>
> My friend and I started Indelible[1] (now defunct) for a lot of the
> same reasons you want to build a datastore -- there aren't enough
> options for a datastore that's immutable, relational,
> highly-vaailable, and private.. We're still super-passionate about the
> ideas, love Datomic but want something a bit different, decided not to
> commercialize it and start more simply with just the data structure.
> We don't want a huge thing, just a library, to keep coordination down;
> the complexity doesn't spread out of the client.
>
> Where we are at now is we have a great versioned immutable B-Tree-like

Re: The database I wish I had a month ago

From EuAndreh to ~euandreh/public-inbox

Jonas Schürmann <me@jonas-schuermann.name> writes:

> Yes, exactly. The idea is pretty abstract and while I know a little bit
> about category theory I'm by no means an expert on the subject. This
> blog post [1] is a very down-to-earth, practical explanation how the
> concept of (co)completed categories can be applied to conflict
> representation in version control systems.
>
> [1] https://jneem.github.io/merging/

This sounds interesting, thanks for the link.

Re: The database I wish I had a month ago

From EuAndreh to ~euandreh/public-inbox

This is some rich discussion, thanks for engaging!

Richard Newman <rnewman@twinql.com> writes:

> Mostly the usual stuff you get when a thing is defined by its
> implementation:
>
> https://github.com/mozilla/mentat/pull/665
> https://github.com/mozilla/mentat/issues/412
>
> There are probably more if you poke around the issue tracker.

Thanks for the references.

Re: Making a database a month ago

From EuAndreh to ~euandreh/public-inbox

"Seph Gentle" <me@josephg.com> writes:

> This is worth watching if you haven’t seen it. Martin is at the forefront of the field - but this gives you a sense of where the research tech is at:
>
> https://martin.kleppmann.com/2020/07/06/crdt-hard-parts-hydra.html

Coincidentally, that's the  third item on my list 😬