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.
+[projektas]
Ar turite omenyje kažką panašaus, kad objektai yra tik mutuojančių užklausų produktai, todėl norime gerai apibrėžtos būsenos erdvės?
// ORM šiek tiek sulieja linijas. Kas būtų, jei galėtume tyliai paversti vieną formą į kitą
Norėdami suskaidyti objektą į užklausas, turite turėti mutacijų istoriją, šiek tiek panašią į saugyklos būsenos pokyčių istoriją.
Akivaizdu, kad kiekvieną objektą galima suskaidyti į užklausas, kurios jį suformavo, pateikiant kiekvieno iš jų istoriją. Ar siūlote turėti kiekvieno tipo objektų istoriją, ar aš tai teisingai suprantu? Arba siūlote mums perkelti duomenis į versijinę duomenų saugyklą, kuri yra šiek tiek panaši į „git“? Kaip tai veiktų praktikoje?
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?
Iš esmės noriu konvertuoti kodą AST į efektyvią užklausą, kurią gali vykdyti duomenų bazė.
Tarkime, kad ieškojau knygų, kurių reitingas 10/10
books = load_from_server_json ('knygos')
geros_knygos = []
knygoms knygose {
Jei knyga ["įvertinimas"] == 10 (
good_books.append (knyga)
}
}
Tai būtų paversta tokia užklausa
Pasirinkite * iš knygų, kurių įvertinimas = 10
Tai tampa sudėtingiau, kai yra objektų grafikas, kuriame yra manipuliuojama keliais laukais. Kaip sakote, turėsite turėti kodą, kuris atsektų mutacijas, kad išsiaiškintumėte, kaip sukurti veiksmingą užklausą, įtraukiančią sujungimus.
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 (
good_books.append(book)
}
}
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.
Ar šis išradimas būtų savotiškas „ORM“, palaikantis duomenų mutacijų grafiko sudarymą iš dėžutės?
Would this invention be a kind of "ORM", that supports making data mutation graph out of the box?
Tai būtų ORM forma. ORM seka atskirų įrašų nešvarumus, o ne masinius įrašus.
Tikslas yra rasti efektyvesnius rankinio kodo vaizdus ir paversti juos efektyviais užklausomis.
Kilpų (ir ORM) problema yra ta, kad reikia, kad duomenys būtų atmintyje. Duomenų bazė geriau peržiūri įrašus į atmintį, nei naiviai parašytas kodas, kuris įkelia viską iš karto.
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.
O, jūs turite galvoje vertėją AST į efektyvų SQL vertėją?
Kai galvojate apie AST ir kad tai gali padaryti daugybę kilpų per objektus, kurti ir tikrinti ypatybes ir kaip tai perrašyti į efektyvią SQL užklausą, kartais tai gali būti iššūkis, o jūs norėtumėte sistemos, kuri automatiškai išverskite savo procedūrinę užklausą į efektyvią SQL deklaratyviąją užklausą.
Kalbant apie „Infinity family“ / „Homebase“, tai galėtume padaryti rankiniu būdu optimizuodami duomenų bazę ir kartu dirbdami su DB modeliu, kitaip tariant, optimizuodami DB modelio (kuris tarnauja kaip ontologija) normalizavimą.
Tačiau, jei norite automatiškai pasiekti tokį dalyką, manau, kad tai yra iššūkis AI sričiai, verčiant kalbas (AST į SQL), nors galbūt tai būtų paprastesnė vertimo versija, nes algoritmai duomenų funkcijos, reikalingos SQL užklausai atlikti, jau būtų įterptos į AST, tereikia rasti gerų SQL antrinių užklausų („struktūrinė užklausos kalba“-manau, kad pats SQL pavadinimas reiškia, kad galime atlikti struktūrizuotą -užklausos, kad būtų pasiektas galutinis užklausos rezultatas).
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).