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.

(通知しない) (不必要) ログインしてください。


// ORMは線を少しぼかします。あるフォームを別のフォームに静かに変換できたらどうなるでしょうか



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?



books = load_from_server_json( 'books')

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
    :  -- 



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

それはORMの一形態になります。 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
    :  -- 
    :  -- 




Infinityファミリ/ Homebaseに関しては、データベースを手動で最適化し、DBモデルを一緒に操作する、つまりDBモデル(オントロジーとして機能)の正規化を最適化することで、これを行うことができます。

ただし、この種のことを自動的に実現したい場合は、言語変換(ASTからSQL)におけるAIドメインの課題だと思いますが、計算するアルゴリズムが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).