Anyone using/used with a lattice database or data structure or considering one?

What sort of use case are you thinking about, @Ian Rumac?

Well, I’m making a tree syntax editor and I store all the generated graphs/trees in a lattice structure, and it seems really useful for storing and retrieving information and connecting it through multiple “dimensions” aka “tables”, so just wondering in general if anyone is using them.

do you mean in the math sense? don’t crdts form a lattice?

@Ian Rumac Do you have any pointers to resources that you can recommend about this? What comes to my mind first is CRDTs, which are usually semi-lattice structures used in what seems to be a slightly different use case than what you have in mind…?

loll was struggling to remember if they were semi lattices or not! but yeah it sounds like a different (and maybe more interesting) data structure. or it’s multidimensional arrays? idk

Yeah, my math knowledge isn’t as deep as I’d like it to be with lattices and semi-lattices, so I wonder what the more restrictively defined lattice structure gives you over a semi-lattice? I can only imagine that you could use that for indexing, maybe? Would be great to hear more about your use case and the benefits you can derive from lattices for it, @Ian Rumac.

Hmm, I guess I might have the wrong thing on my mind then, apologies for misleading, I’m not really good at that level of math and might have had something wrong while researching 😅! What I’m calling a lattice is having graphs/sets A,B,C..n in which elements of B can be elements of A but with a transformation applied. Like having a graph A and graph B and node X from B is actually X from A with a transformation applied and different relationships. So my lattice structure is a structure containing all those nodes and their relationships in each set (edges) they’re a member of or connected to. Basically an array of graphs where each node can exist in multiple graphs and have different relationships in each, but it’s always the same node just with a transformation applied for that graph type. So if you have an X in set D, you can always get relationships of X in set A.

Thanks for clarifying, @Ian Rumac! It doesn’t sound dumb at all. What is your motivation? Are you trying to stay flexible with the data model and/or does it change frequently? Are your sets (which I understand model the edges in a graph?) small, just modeling relationships between few nodes, but then you deal with a large number of edges? Theoretically, you could model everything with just binary relationships and take advantage of all the standards graph algorithms, but there are obvious benefits of being able to attach metadata to those edges and factor out some of your data model into such metadata. That would put you into classic graph database territory. Have you considered using a graph database and if so what made you decide against it? If your sets for modeling relationships have more than two nodes, do they all have the same number or does it vary? In that case, or maybe in general, a more specific example with perhaps actual data could be enlightening. And I guess the most interesting question is: you asked if somebody here has played with this — I’m still not sure I did, because I’m still not sure what this is, but… what other questions do you have?

@Stefan Yeah, I deal with a large number of edge - I’m trying to stay flexible with the data model and give the possibility to extend my “editor” with custom models. I was thinking of a graph database but wanted a temporary in-memory solution so I made this, now I’m wondering if there’s similar solutions I can look up because I find it quite good to use. My usecase, for example: You define a model for your database, by let’s say, using graphql:

type User{
 id: ID!,
email: String,
   name: String,
   post: Post
}
type Post {
  id: ID!
  content: String
}

It’s saved in: Types set (I call them dimensions, gives more context, hope you don’t mind) as User, Post and the same elements in graphql dimension have relationships to their properties which, when in type dimension are connected to String, ID, etc… Now, let’s say I wanna create a postgresql database - I just create the postgresql dimension from Graphql dimension and have the scheme generated by using transformations from graphql-postgres dimension. Then in, let’s say, kotlin backend dimension, I can generate my backend Kotlin entities, queries and etc by just creating a Kotlin backend dimension and automatically having it filled out by having transformation rules applied (graphql-kotlin backend transformation) - and when I update a definition in the graphql dimension, the changes can be propagated across all sets and say “hey, this update broke this” and automatically have changes applied.

this sounds similar to datomic, fulcro/pathos, and materialized views in apache samza. links incoming

@Ian Rumac Very interesting! So you basically use transform functions to build schemas on the fly and that's your main reason for that architecture? Are you just regenerating them when the model changes and wipe all the data in the downstream systems, or have you thought about migrations to keep the data in those systems and adapt the schemas (a decade ago when I was doing Ruby that was a hot thing in Ruby on Rails with Active Record; I assume that's still around but probably not that special anymore…).

Yes, that’s basically the reason I went for this, seemed quick to write and useful in the time. I just propagate the change actions for now and update every related node, but I assume this isn’t scalable, so I assume I’ll just add in some kind of logical clock and then check for updates later. I’m concerned with migrations + custom changes, but not yet that far in the project. Also thanks Garth! I’ll look over the material and hopefully have a better language to discuss it in!