Graph manipulation to queries


Typically with an information system there are two ways of writing systems - one is predominantly through mutating queries and the other is through manipulation of objects in memory such as references between objects. ORMs blur the lines a bit. What if we could silently transform one form to another


This idea is to take code that manipulates objects in memory through dereferences and loops to be automatically rewritten to query based logic.

For loops and while loops can be replaced with queries with conditions on automatically.

Infinity family or homebase is about an ontology that defines objects and their relationships. We also want the operations to be clearly definable and efficient.

(别通知) (可选) 请,登录

哦,你的意思是翻译 AST 到高效的 SQL 翻译?

当您考虑 AST 时,它可以对对象进行多次循环,创建和检查属性,以及如何将其重写为高效的 SQL 查询,有时这可能是一个挑战,您希望有一个系统可以自动执行将您的过程查询转换为高效的 SQL 声明式查询。

对于Infinity family / Homebase,我们可以通过手动优化数据库,一起做DB模型,也就是优化DB模型(作为本体)的规范化。

然而,如果你想自动实现这种事情,我认为,这对 AI 领域来说是一个挑战,在语言翻译(AST 到 SQL)方面,不过,它可能是一个更简单的翻译版本,因为计算执行 SQL 查询所需的数据特征已经嵌入到 AST 中,只需要为 SQL 找到好的子查询(“结构化查询语言”——我认为 SQL 名称本身暗示,我们可以做结构化子-查询到达查询的最终结果)。

Oh, you mean translator AST to efficient SQL translator?

When you think about AST, and that it could be doing many loops over objects, creating and checking properties, and how to rewrite that into an efficient SQL query, it can sometimes be a challenge, and you'd like a system that would automatically translate your procedural query into efficient SQL declarative query.

When it comes to Infinity family / Homebase, we could do this by manually optimizing the database, and working on the DB model together, in other words, optimizing the normalization of DB model (that serves as ontology).

However, if you want to achieve this kind of thing automatically, I think, it's a challenge for AI domain, in language translation (AST to SQL), though, it would perhaps be a simpler version of translation, because the algorithms to compute the data features required to do an SQL query would be already embedded in the AST, one would just need to find good sub-queries for SQL ("structured query language" -- I think the SQL name itself implies, that we can do structured sub-queries to arrive at the final result of query).

这将是 ORM 的一种形式。 ORM 跟踪单个记录的脏度,而不是批量记录。


for 循环(和 ORM)的问题在于您需要数据在内存中。数据库更擅长将记录分页到内存中,而不是一次加载所有记录的天真编写的代码。

It would be a form of ORM. ORMs track dirtiness of individual records not bulk records.

The goal is to find more efficient representations of manual code and convert it to efficient queries.

The problem with for loops (and ORMs) is that you require the data be in memory. The database is better at paging in records into memory than naively written code that loads it all at once.

    : Mindey
    :  -- 
    :  -- 



Would this invention be a kind of "ORM", that supports making data mutation graph out of the box?

本质上,我想将代码 AST 转换为数据库可以执行的高效查询。

假设我正在寻找评分为 10/10 的书籍

书籍 = load_from_server_json('书籍')

good_books = []


如果 book["rating"] == 10 (





从评分 = 10 的书籍中选择 *


Essentially I want to transform code AST into an efficient query that a database can execute.

Say I was looking for books with a rating of 10/10

books = load_from_server_json('books')

good_books = []

for book in books {

If book["rating"] == 10 (




This would be transformed into the following query

Select * from books where rating = 10

It gets more complicated when there is a graph of objects where there is manipulations to multiple fields. Like you say, you would have to have the code trace the mutations to work out how to generate an efficient query that incorporated joins.

    :  -- 
    : Mindey
    :  -- 



// ORM 使线条模糊了一点。如果我们可以默默地将一种形式转变为另一种形式会怎样

要将对象分解为查询,您必须有一个突变历史,有点像存储库状态更改的 git 历史。

通过为每个对象提供历史记录,显然可以将每个对象分解为形成它的查询。您是否提议为每种对象类型提供历史记录,我理解正确吗?或者,您是否建议我们将数据移动到版本化数据存储,这有点像 git?这在实践中如何运作?

Do you mean something along the lines, that objects are just products of mutating queries, so we want a well-defined state space?

// ORMs blur the lines a bit. What if we could silently transform one form to another

To decompose an object into queries, you'd have to have a history of mutations, a bit like git history of repository state changes.

It is obviously possible to decompose each object into queries that formed it by providing a history for each of them. Are you proposing to have histories for each object types, am I understanding it correctly? Or, are you suggesting us moving the data to a versioned data storage, that is a bit like git? How would this work in practice?