From 741fac0a98680988a546adde06f1a0b28e8ec45f Mon Sep 17 00:00:00 2001 From: facebook-github-bot Date: Wed, 10 Jan 2024 20:29:49 +0000 Subject: [PATCH] =?UTF-8?q?Deploying=20to=20gh-pages=20from=20=20@=20746f6?= =?UTF-8?q?d77714944a6cb9cea21a8d21ae66ad20f4f=20=F0=9F=9A=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 404.html | 4 ++-- _src/angle/guide.md | 2 +- assets/js/{7c10977a.1d06462e.js => 7c10977a.cb3a5eb2.js} | 2 +- .../{runtime~main.ad5399c4.js => runtime~main.67e379df.js} | 2 +- blog/archive/index.html | 4 ++-- blog/incremental/index.html | 4 ++-- blog/index.html | 4 ++-- blog/tags/glean/index.html | 4 ++-- blog/tags/incremental/index.html | 4 ++-- blog/tags/index.html | 4 ++-- docs/angle/advanced/index.html | 4 ++-- docs/angle/debugging/index.html | 4 ++-- docs/angle/efficiency/index.html | 4 ++-- docs/angle/guide/index.html | 6 +++--- docs/angle/intro/index.html | 4 ++-- docs/angle/reference/index.html | 4 ++-- docs/angle/style/index.html | 4 ++-- docs/building/index.html | 4 ++-- docs/cli/index.html | 4 ++-- docs/databases/index.html | 4 ++-- docs/derived/index.html | 4 ++-- docs/implementation/incrementality/index.html | 4 ++-- docs/indexer/cxx/index.html | 4 ++-- docs/indexer/flow/index.html | 4 ++-- docs/indexer/hack/index.html | 4 ++-- docs/indexer/haskell/index.html | 4 ++-- docs/indexer/intro/index.html | 4 ++-- docs/indexer/lsif-go/index.html | 4 ++-- docs/indexer/lsif-java/index.html | 4 ++-- docs/indexer/lsif-rust/index.html | 4 ++-- docs/indexer/lsif-typescript/index.html | 4 ++-- docs/indexer/scip-dotnet/index.html | 4 ++-- docs/indexer/scip-python/index.html | 4 ++-- docs/introduction/index.html | 4 ++-- docs/query/api/haskell/index.html | 4 ++-- docs/query/haskell/index.html | 4 ++-- docs/query/intro/index.html | 4 ++-- docs/running/index.html | 4 ++-- docs/schema/all/index.html | 4 ++-- docs/schema/basic/index.html | 4 ++-- docs/schema/changing/index.html | 4 ++-- docs/schema/design/index.html | 4 ++-- docs/schema/recursion/index.html | 4 ++-- docs/schema/syntax/index.html | 4 ++-- docs/schema/thrift/index.html | 4 ++-- docs/schema/types/index.html | 4 ++-- docs/schema/workflow/index.html | 4 ++-- docs/server/index.html | 4 ++-- docs/shell/index.html | 4 ++-- docs/trying/index.html | 4 ++-- docs/walkthrough/index.html | 4 ++-- docs/write/index.html | 4 ++-- index.html | 4 ++-- 53 files changed, 104 insertions(+), 104 deletions(-) rename assets/js/{7c10977a.1d06462e.js => 7c10977a.cb3a5eb2.js} (83%) rename assets/js/{runtime~main.ad5399c4.js => runtime~main.67e379df.js} (99%) diff --git a/404.html b/404.html index 8c8920190..d5a75108c 100644 --- a/404.html +++ b/404.html @@ -5,14 +5,14 @@ Page Not Found | Glean - +
Skip to main content

Page Not Found

We could not find what you were looking for.

Please contact the owner of the site that linked you to the original URL and let them know their link is broken.

- + \ No newline at end of file diff --git a/_src/angle/guide.md b/_src/angle/guide.md index 1720d2293..6f0fa0b54 100644 --- a/_src/angle/guide.md +++ b/_src/angle/guide.md @@ -493,7 +493,7 @@ facts> C where C = example.Class _; !(example.Has { class_ = C, has = { method = Or we could find the maximum element in an array ```lang=angle -facts> X where Values = [5,1,2,3]; X = Values[..]; !(Y = Values[..]; Y > X); +facts> X where Values = [5,1,2,3]; X = Values[..]; !(Y = Values[..]; Y > X) { "id": 1091, "key": 5 } ``` diff --git a/assets/js/7c10977a.1d06462e.js b/assets/js/7c10977a.cb3a5eb2.js similarity index 83% rename from assets/js/7c10977a.1d06462e.js rename to assets/js/7c10977a.cb3a5eb2.js index 0f394aba2..ffb69d165 100644 --- a/assets/js/7c10977a.1d06462e.js +++ b/assets/js/7c10977a.cb3a5eb2.js @@ -1 +1 @@ -"use strict";(self.webpackChunkwebsite=self.webpackChunkwebsite||[]).push([[3627],{3905:(e,n,a)=>{a.r(n),a.d(n,{MDXContext:()=>d,MDXProvider:()=>c,mdx:()=>f,useMDXComponents:()=>p,withMDXComponents:()=>m});var t=a(67294);function i(e,n,a){return n in e?Object.defineProperty(e,n,{value:a,enumerable:!0,configurable:!0,writable:!0}):e[n]=a,e}function l(){return l=Object.assign||function(e){for(var n=1;n=0||(i[a]=e[a]);return i}(e,n);if(Object.getOwnPropertySymbols){var l=Object.getOwnPropertySymbols(e);for(t=0;t=0||Object.prototype.propertyIsEnumerable.call(e,a)&&(i[a]=e[a])}return i}var d=t.createContext({}),m=function(e){return function(n){var a=p(n.components);return t.createElement(e,l({},n,{components:a}))}},p=function(e){var n=t.useContext(d),a=n;return e&&(a="function"==typeof e?e(n):s(s({},n),e)),a},c=function(e){var n=p(e.components);return t.createElement(d.Provider,{value:n},e.children)},u={inlineCode:"code",wrapper:function(e){var n=e.children;return t.createElement(t.Fragment,{},n)}},h=t.forwardRef((function(e,n){var a=e.components,i=e.mdxType,l=e.originalType,r=e.parentName,d=o(e,["components","mdxType","originalType","parentName"]),m=p(a),c=i,h=m["".concat(r,".").concat(c)]||m[c]||u[c]||l;return a?t.createElement(h,s(s({ref:n},d),{},{components:a})):t.createElement(h,s({ref:n},d))}));function f(e,n){var a=arguments,i=n&&n.mdxType;if("string"==typeof e||i){var l=a.length,r=new Array(l);r[0]=h;var s={};for(var o in n)hasOwnProperty.call(n,o)&&(s[o]=n[o]);s.originalType=e,s.mdxType="string"==typeof e?e:i,r[1]=s;for(var d=2;d{a.r(n),a.d(n,{assets:()=>d,contentTitle:()=>s,default:()=>c,frontMatter:()=>r,metadata:()=>o,toc:()=>m});var t=a(83117),i=(a(67294),a(3905)),l=a(44256);const r={id:"guide",title:"Angle Guide",sidebar_label:"Guide"},s=void 0,o={unversionedId:"angle/guide",id:"angle/guide",title:"Angle Guide",description:"The following guide will explain Angle from first principles, leading you through from simple queries to more complex ones.",source:"@site/docs/angle/guide.md",sourceDirName:"angle",slug:"/angle/guide",permalink:"/docs/angle/guide",draft:!1,editUrl:"https://github.com/facebookincubator/Glean/tree/main/glean/website/docs/angle/guide.md",tags:[],version:"current",frontMatter:{id:"guide",title:"Angle Guide",sidebar_label:"Guide"},sidebar:"someSidebar",previous:{title:"Introduction",permalink:"/docs/angle/intro"},next:{title:"Query Efficiency",permalink:"/docs/angle/efficiency"}},d={},m=[{value:"Just the facts",id:"just-the-facts",level:2},{value:"Matching nested facts",id:"matching-nested-facts",level:2},{value:"Union types",id:"union-types",level:2},{value:"Maybe",id:"maybe",level:2},{value:"Or-patterns",id:"or-patterns",level:2},{value:"If-patterns",id:"if-patterns",level:2},{value:"More complex queries",id:"more-complex-queries",level:2},{value:"Statements",id:"statements",level:2},{value:"Arrays",id:"arrays",level:2},{value:"String prefix",id:"string-prefix",level:2},{value:"Tuples",id:"tuples",level:2},{value:"Enums and bool",id:"enums-and-bool",level:2},{value:"Negation",id:"negation",level:2}],p={toc:m};function c(e){let{components:n,...a}=e;return(0,i.mdx)("wrapper",(0,t.Z)({},p,a,{components:n,mdxType:"MDXLayout"}),(0,i.mdx)("p",null,"The following guide will explain Angle from first principles, leading you through from simple queries to more complex ones."),(0,i.mdx)("p",null,"If you want to try the examples for yourself, or experiment with\nchanges to the example schema, you should first follow the\ninstructions in ",(0,i.mdx)("a",{parentName:"p",href:"/docs/walkthrough"},"Walkthrough")," to get set up."),(0,i.mdx)(l.FbInternalOnly,{mdxType:"FbInternalOnly"},(0,i.mdx)("p",null,"There are also ",(0,i.mdx)("a",{parentName:"p",href:"https://www.internalfb.com/intern/wiki/Glean/Query/Angle/Angle_examples/"},"examples of using Angle")," to query real data.")),(0,i.mdx)("h2",{id:"just-the-facts"},"Just the facts"),(0,i.mdx)("p",null,"Data in Glean is described by a ",(0,i.mdx)("em",{parentName:"p"},"schema"),", which we normally put in a file with the extension ",(0,i.mdx)("inlineCode",{parentName:"p"},"angle"),". For the purposes of this guide we\u2019ll use the example schema in ",(0,i.mdx)("inlineCode",{parentName:"p"},"example.angle"),". Full details about defining schemas can be found in ",(0,i.mdx)("a",{parentName:"p",href:"/docs/schema/basic"},"Schemas"),". The ",(0,i.mdx)("inlineCode",{parentName:"p"},"example.angle")," file contains a schema definition like this:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},"schema example.1 {\n\n# definitions go here\n\n}\n")),(0,i.mdx)("p",null,"This says we\u2019re defining a schema called ",(0,i.mdx)("inlineCode",{parentName:"p"},"example"),", with version 1."),(0,i.mdx)("p",null,"The schema contains definitions for ",(0,i.mdx)("em",{parentName:"p"},"predicates"),". A predicate is the type of ",(0,i.mdx)("em",{parentName:"p"},"facts"),", which are the individual pieces of information that Glean stores. Our example schema models a simplified class hierarchy for an object-oriented language, starting with a predicate for a ",(0,i.mdx)("inlineCode",{parentName:"p"},"Class"),":"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},"predicate Class :\n {\n name : string,\n line : nat,\n }\n")),(0,i.mdx)("p",null,"This says that the facts of ",(0,i.mdx)("inlineCode",{parentName:"p"},"Class")," are records with two fields, a ",(0,i.mdx)("inlineCode",{parentName:"p"},"name")," field which contains a ",(0,i.mdx)("inlineCode",{parentName:"p"},"string"),", and a ",(0,i.mdx)("inlineCode",{parentName:"p"},"line")," field which contains a ",(0,i.mdx)("inlineCode",{parentName:"p"},"nat")," (\u201cnat\u201d is short for \u201cnatural number\u201d, which is limited to 64 bits in Glean)."),(0,i.mdx)("p",null,"The simplest type of Angle query is one that just selects facts from\nthe database that match a pattern. For our first Angle query, let\u2019s\nfind a class by its name:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre"},'facts> example.Class { name = "Pet" }\n{ "id": 1024, "key": { "name": "Pet", "line": 10 } }\n\n1 results, 1 facts, 4.61ms, 117632 bytes, 677 compiled bytes\n')),(0,i.mdx)("p",null,"(The last line contains statistics about query performance from Glean; I\u2019ll leave this out in the rest of the examples.)"),(0,i.mdx)("p",null,"What\u2019s going on here?"),(0,i.mdx)("ul",null,(0,i.mdx)("li",{parentName:"ul"},"The query consists of the ",(0,i.mdx)("em",{parentName:"li"},"predicate name")," ",(0,i.mdx)("inlineCode",{parentName:"li"},"example.Class")," followed by a ",(0,i.mdx)("em",{parentName:"li"},"pattern")," ",(0,i.mdx)("inlineCode",{parentName:"li"},'{ name = "Pet" }')),(0,i.mdx)("li",{parentName:"ul"},"Note that when we refer to a predicate in a query, the name is ",(0,i.mdx)("em",{parentName:"li"},"qualified")," by prefixing the schema name, so it\u2019s ",(0,i.mdx)("inlineCode",{parentName:"li"},"example.Class")," rather than just ",(0,i.mdx)("inlineCode",{parentName:"li"},"Class"),"."),(0,i.mdx)("li",{parentName:"ul"},"The query returns all the facts of ",(0,i.mdx)("inlineCode",{parentName:"li"},"example.Class")," that match the pattern")),(0,i.mdx)("p",null,"The shell shows results in JSON format. When you\u2019re making Glean\nqueries from code, the results will normally be decoded into native\ndata types that you can manipulate directly in whatever language\nyou\u2019re using; for more details see ",(0,i.mdx)("a",{parentName:"p",href:"/docs/schema/thrift"},"Thrift and\nJSON"),"."),(0,i.mdx)("p",null,"Note that each fact has a unique ",(0,i.mdx)("inlineCode",{parentName:"p"},"id"),". This is how Glean identifies facts in its database. As a user you normally won\u2019t have to worry about fact ",(0,i.mdx)("inlineCode",{parentName:"p"},"id"),"s; you can think of them like memory addresses."),(0,i.mdx)("p",null,"The pattern specifies which facts to return. In the example above, our pattern is matching a record type and specifying a subset of the fields: just the ",(0,i.mdx)("inlineCode",{parentName:"p"},"name")," field. We could match the ",(0,i.mdx)("inlineCode",{parentName:"p"},"line")," field instead:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=sh"},'facts> example.Class { line = 20 }\n{ "id": 1025, "key": { "name": "Lizard", "line": 20 } }\n')),(0,i.mdx)("admonition",{type:"note"},(0,i.mdx)("p",{parentName:"admonition"},"Your patterns should normally match fields at the ",(0,i.mdx)("em",{parentName:"p"},"beginning")," of the\nrecord, because facts in the database are indexed by a prefix of the\nfields. Matching a field in the middle of the record works by scanning\nall the facts, which could be expensive. We\u2019ll get into this in more\ndetail in ",(0,i.mdx)("a",{parentName:"p",href:"/docs/angle/efficiency"},"Query Efficiency"),".")),(0,i.mdx)("p",null,'What other kinds of patterns can we use? Well, the simplest patterns are the wildcard, \u201c_\u201d, which matches anything, and "never", which always fails to match.'),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> example.Class _\n{ "id": 1026, "key": { "name": "Fish", "line": 30 } }\n{ "id": 1027, "key": { "name": "Goldfish", "line": 40 } }\n{ "id": 1025, "key": { "name": "Lizard", "line": 20 } }\n{ "id": 1024, "key": { "name": "Pet", "line": 10 } }\nfacts> example.Class never\n(no results)\n')),(0,i.mdx)("p",null,"We\u2019ll introduce more kinds of pattern in the following sections. The full list of patterns can be found in ",(0,i.mdx)("a",{parentName:"p",href:"/docs/angle/reference"},"Angle Reference"),"."),(0,i.mdx)("h2",{id:"matching-nested-facts"},"Matching nested facts"),(0,i.mdx)("p",null,"The real power of Glean comes from relationships between facts. Facts can refer directly to other facts, and we can write queries that directly match on these connections."),(0,i.mdx)("p",null,"Our example schema has a predicate that expresses the inheritance relationship between classes:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},"predicate Parent :\n {\n child : Class,\n parent : Class,\n }\n")),(0,i.mdx)("p",null,"Let\u2019s find what ",(0,i.mdx)("inlineCode",{parentName:"p"},"Fish")," inherits from:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> example.Parent { child = { name = "Fish" }}\n{\n "id": 1029,\n "key": { "child": { "id": 1026, "key": { "name": "Fish", "line": 30 } }, "parent": { "id": 1024, "key": { "name": "Pet", "line": 10 } } }\n}\n')),(0,i.mdx)("p",null,"Let\u2019s break this down."),(0,i.mdx)("ul",null,(0,i.mdx)("li",{parentName:"ul"},(0,i.mdx)("inlineCode",{parentName:"li"},'{ child = { name = "Fish" }}')," is a pattern that matches the key type of ",(0,i.mdx)("inlineCode",{parentName:"li"},"Parent")),(0,i.mdx)("li",{parentName:"ul"},"So, looking at the schema, ",(0,i.mdx)("inlineCode",{parentName:"li"},'{ name = "Fish" }')," is a pattern that should match the ",(0,i.mdx)("inlineCode",{parentName:"li"},"Class")," in the field ",(0,i.mdx)("inlineCode",{parentName:"li"},"child"),".")),(0,i.mdx)("p",null,"By default Angle queries recursively expand facts in the results. We can see in the above result that the ",(0,i.mdx)("inlineCode",{parentName:"p"},"child")," and ",(0,i.mdx)("inlineCode",{parentName:"p"},"parent")," fields contain the full facts they point to. If we want the result to be \u201cshallow\u201d, meaning it contains just the facts that match and not the nested facts, we can ask Glean to not expand the content of those references. In the shell this is done by running the command ",(0,i.mdx)("inlineCode",{parentName:"p"},":expand off"),":"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> :expand off\nfacts> example.Parent { child = { name = "Fish" }}\n{ "id": 1029, "key": { "child": { "id": 1026 }, "parent": { "id": 1024 } } }\n')),(0,i.mdx)("p",null,"We can of course go the other way and find all the children of a class:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> example.Parent { parent = { name = "Pet" }}\n{\n "id": 1028,\n "key": {\n "child": { "id": 1025, "key": { "name": "Lizard", "line": 20 } },\n "parent": { "id": 1024, "key": { "name": "Pet", "line": 10 } }\n }\n}\n{\n "id": 1029,\n "key": {\n "child": { "id": 1026, "key": { "name": "Fish", "line": 30 } },\n "parent": { "id": 1024, "key": { "name": "Pet", "line": 10 } }\n }\n}\n')),(0,i.mdx)("p",null,"But as before, note that this would be an inefficient query if we had a lot of data because the pattern is matching on the second field of ",(0,i.mdx)("inlineCode",{parentName:"p"},"Parent")," (namely ",(0,i.mdx)("inlineCode",{parentName:"p"},"parent"),"). Later we\u2019ll see how to make these queries more efficient using a derived predicate."),(0,i.mdx)("h2",{id:"union-types"},"Union types"),(0,i.mdx)("p",null,"Our examples so far have dealt with record types. Glean also supports ",(0,i.mdx)("em",{parentName:"p"},"union types"),", also called ",(0,i.mdx)("em",{parentName:"p"},"sum types"),", which are used to express multiple alternatives. For example, let\u2019s expand our schema to include class members which can be either a method or a variable:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},"predicate Has :\n {\n class_ : Class,\n has : Member,\n access : enum { Public | Private },\n }\n\npredicate Member :\n {\n method : { name : string, doc : maybe string } |\n variable : { name : string }\n }\n}\n")),(0,i.mdx)("p",null,"The predicate ",(0,i.mdx)("inlineCode",{parentName:"p"},"Has")," maps a ",(0,i.mdx)("inlineCode",{parentName:"p"},"Class")," to a ",(0,i.mdx)("inlineCode",{parentName:"p"},"Member")," (with a ",(0,i.mdx)("inlineCode",{parentName:"p"},"Public")," or ",(0,i.mdx)("inlineCode",{parentName:"p"},"Private")," annotation), and a ",(0,i.mdx)("inlineCode",{parentName:"p"},"Member")," is either ",(0,i.mdx)("inlineCode",{parentName:"p"},"method")," or ",(0,i.mdx)("inlineCode",{parentName:"p"},"variable"),", with some associated data. Note that a ",(0,i.mdx)("inlineCode",{parentName:"p"},"Class")," might have more than one ",(0,i.mdx)("inlineCode",{parentName:"p"},"Member"),", which is fine: there can be multiple ",(0,i.mdx)("inlineCode",{parentName:"p"},"Has")," facts for a given ",(0,i.mdx)("inlineCode",{parentName:"p"},"Class"),"."),(0,i.mdx)("admonition",{type:"note"},(0,i.mdx)("p",{parentName:"admonition"},"The schema uses ",(0,i.mdx)("inlineCode",{parentName:"p"},"class_")," rather than ",(0,i.mdx)("inlineCode",{parentName:"p"},"class")," as a field name, because ",(0,i.mdx)("inlineCode",{parentName:"p"},"class")," is a reserved word in Angle. There are many such reserved words, which are reserved not because Angle uses them, but because they cause problems for code that is automatically generated from the schema. To avoid having too many ad-hoc language-specific naming rules, Glean prevents certain problematic names from being used in the schema. The Angle compiler will tell you if you try to use a reserved word.")),(0,i.mdx)("p",null,"Let\u2019s find classes that have a variable called ",(0,i.mdx)("inlineCode",{parentName:"p"},"fins"),":"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> example.Has { has = { variable = { name = "fins" }}}\n{\n "id": 1036,\n "key": {\n "class_": { "id": 1026, "key": { "name": "Fish", "line": 30 } },\n "has": { "id": 1035, "key": { "variable": { "name": "fins" } } },\n "access": 1\n }\n}\n')),(0,i.mdx)("p",null,"The key thing here is that we matched on ",(0,i.mdx)("inlineCode",{parentName:"p"},"Member")," which is a union type, using the pattern ",(0,i.mdx)("inlineCode",{parentName:"p"},'{ variable = { name = "fins" }}'),". A pattern to match a union type looks very much like a record pattern, but it can have only a single field, in this case either ",(0,i.mdx)("inlineCode",{parentName:"p"},"variable")," or ",(0,i.mdx)("inlineCode",{parentName:"p"},"method"),"."),(0,i.mdx)("h2",{id:"maybe"},"Maybe"),(0,i.mdx)("p",null,"Glean has one built-in union type called ",(0,i.mdx)("inlineCode",{parentName:"p"},"maybe"),", which is useful when we want to have optional values in the data. It's used in our example schema to attach optional documentation to a class member:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},"predicate Member :\n {\n method : { name : string, doc : maybe string } |\n variable : { name : string }\n }\n")),(0,i.mdx)("p",null,"The type ",(0,i.mdx)("inlineCode",{parentName:"p"},"maybe string")," behaves exactly as if it were defined as the union type ",(0,i.mdx)("inlineCode",{parentName:"p"},"{ nothing | just : string }"),". That means we can write a pattern that matches it, exactly as we would write a pattern for ",(0,i.mdx)("inlineCode",{parentName:"p"},"{ nothing | just : string }"),":"),(0,i.mdx)("p",null,"Methods without documentation:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre"},"facts> example.Member { method = { doc = nothing } }\n")),(0,i.mdx)("p",null,"Methods with documentation:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre"},"facts> example.Member { method = { doc = { just = _ }}}\n")),(0,i.mdx)("h2",{id:"or-patterns"},"Or-patterns"),(0,i.mdx)("p",null,"In a pattern we can express multiple alternatives by separating patterns with a vertical bar ",(0,i.mdx)("inlineCode",{parentName:"p"},"|"),"."),(0,i.mdx)("p",null,"For example, we can find classes on lines 20 or 30:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> example.Class { line = 20 | 30 }\n{ "id": 1025, "key": { "name": "Lizard", "line": 20 } }\n{ "id": 1026, "key": { "name": "Fish", "line": 30 } }\n')),(0,i.mdx)("p",null,"Or we can find all the classes that have either a ",(0,i.mdx)("inlineCode",{parentName:"p"},"method")," called ",(0,i.mdx)("inlineCode",{parentName:"p"},"feed")," or a ",(0,i.mdx)("inlineCode",{parentName:"p"},"variable")," with any name:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> example.Has { has = { method = { name = "feed" }} | { variable = _ }}\n\n(results omitted)\n')),(0,i.mdx)("h2",{id:"if-patterns"},"If-patterns"),(0,i.mdx)("p",null,"We can conditionally match patterns using ",(0,i.mdx)("inlineCode",{parentName:"p"},"if then else"),"."),(0,i.mdx)("p",null,"Variables matched in the condition will be available in the ",(0,i.mdx)("inlineCode",{parentName:"p"},"then")," branch."),(0,i.mdx)("p",null,"Whilst an or-pattern will always evaluate both of its branches, the ",(0,i.mdx)("inlineCode",{parentName:"p"},"else")," branch of an if-pattern will\nnever be evaluated if the condition succeeds at least once."),(0,i.mdx)("p",null,"For example, we could get all child classes if inheritance is being used in the codebase, or\nretrieve all classes if it isn't."),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre"},'facts > if (example.Parent { child = X }) then X else example.Class _\n { "id": 1025, "key": { "name": "Lizard", "line": 20 } }\n { "id": 1026, "key": { "name": "Fish", "line": 30 } }\n { "id": 1027, "key": { "name": "Goldfish", "line": 40 } }\n')),(0,i.mdx)("p",null,"Please note that if-patterns cannot be used in stored derived predicates. This\nis the case because they require the use of negation, which is disallowed in\nstored predicates."),(0,i.mdx)("h2",{id:"more-complex-queries"},"More complex queries"),(0,i.mdx)("p",null,"So far we\u2019ve seen how to query for facts by matching patterns, including matching nested facts. In this section we\u2019ll see how to construct more complex queries that combine matching facts from multiple predicates."),(0,i.mdx)("p",null,"Suppose we want to find all the parents of classes that have a variable called ",(0,i.mdx)("inlineCode",{parentName:"p"},"fins"),". We need to build a query that will"),(0,i.mdx)("ul",null,(0,i.mdx)("li",{parentName:"ul"},"find the classes with a variable called ",(0,i.mdx)("inlineCode",{parentName:"li"},"fins")," using ",(0,i.mdx)("inlineCode",{parentName:"li"},"example.Has")," as we did above"),(0,i.mdx)("li",{parentName:"ul"},"find their parents using ",(0,i.mdx)("inlineCode",{parentName:"li"},"example.Parent"))),(0,i.mdx)("p",null,"We can combine these two as follows:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'example.Has\n {\n class_ = C,\n has = { variable = { name = "fins" }}\n };\nexample.Parent { child = C }\n')),(0,i.mdx)("admonition",{type:"note"},(0,i.mdx)("p",{parentName:"admonition"},"I\u2019ve written this on several lines with indentation to illustrate it\nbetter, to do this in the shell you will need to use the ",(0,i.mdx)("inlineCode",{parentName:"p"},":edit"),"\ncommand to put the query in a temporary file.")),(0,i.mdx)("p",null,"The key thing here is that we used a ",(0,i.mdx)("em",{parentName:"p"},"variable")," ",(0,i.mdx)("inlineCode",{parentName:"p"},"C")," to stand for the ",(0,i.mdx)("inlineCode",{parentName:"p"},"class_")," field when matching facts of ",(0,i.mdx)("inlineCode",{parentName:"p"},"example.Has"),", and then we searched for ",(0,i.mdx)("inlineCode",{parentName:"p"},"example.Parent")," facts with the same value of ",(0,i.mdx)("inlineCode",{parentName:"p"},"C")," for the ",(0,i.mdx)("inlineCode",{parentName:"p"},"child")," field."),(0,i.mdx)("p",null,"Note that variables must ",(0,i.mdx)("em",{parentName:"p"},"always")," begin with an upper-case letter, while schema names (",(0,i.mdx)("inlineCode",{parentName:"p"},"example)")," and field names (",(0,i.mdx)("inlineCode",{parentName:"p"},"child"),") begin with a lower-case letter."),(0,i.mdx)("p",null,"The semicolon separates multiple ",(0,i.mdx)("em",{parentName:"p"},"statements")," in a query. When there are multiple statements the results of the query are the facts that match the last statement, in this case the ",(0,i.mdx)("inlineCode",{parentName:"p"},"example.Parent"),". Let\u2019s try it:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> example.Has { class_ = C, has = { variable = { name = "fins" }}}; example.Parent { child = C }\n{\n "id": 1029,\n "key": {\n "child": { "id": 1026, "key": { "name": "Fish", "line": 30 } },\n "parent": { "id": 1024, "key": { "name": "Pet", "line": 10 } }\n }\n}\n')),(0,i.mdx)("p",null," Suppose we don\u2019t care too much about the child here, we only care about getting a list of the parents. We can avoid returning the redundant information by specifying explicitly what it is we want to return from the query:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'P where\n example.Has\n {\n class_ = C,\n has = { variable = { name = "fins" }}\n };\n example.Parent { child = C, parent = P }\n')),(0,i.mdx)("p",null,"The general form of the query is ",(0,i.mdx)("em",{parentName:"p"},(0,i.mdx)("inlineCode",{parentName:"em"},"expression"))," ",(0,i.mdx)("inlineCode",{parentName:"p"},"where")," ",(0,i.mdx)("em",{parentName:"p"},(0,i.mdx)("inlineCode",{parentName:"em"},"statements")),", where ",(0,i.mdx)("em",{parentName:"p"},(0,i.mdx)("inlineCode",{parentName:"em"},"expression"))," is an arbitrary expression and each statement is a pattern that matches some facts. The results of the query are the distinct values of ",(0,i.mdx)("em",{parentName:"p"},(0,i.mdx)("inlineCode",{parentName:"em"},"expression"))," for which all the statements match facts in the database."),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> P where example.Has { class_ = C, has = { variable = { name = "fins" }}}; example.Parent { child = C, parent = P }\n{ "id": 1024, "key": { "name": "Pet", "line": 10 } }\n')),(0,i.mdx)("h2",{id:"statements"},"Statements"),(0,i.mdx)("p",null,"In general, a statement can be of the form ",(0,i.mdx)("em",{parentName:"p"},"A = B.")," For example, if we write"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'C = example.Class { name = "Fish" };\nexample.Parent { child = C }\n')),(0,i.mdx)("p",null,"that\u2019s the same as"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'example.Parent { child = { name = "Fish" }}\n')),(0,i.mdx)("p",null,"A statement can have a pattern on either side, for example"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'C where\n C = example.Class { name = N };\n N = "Fish" | "Goldfish"\n')),(0,i.mdx)("p",null,"A statement can itself be a set of alternatives separated by a vertical bar ",(0,i.mdx)("inlineCode",{parentName:"p"},"|"),". For example, we can find classes that are either a parent of the ",(0,i.mdx)("inlineCode",{parentName:"p"},"Goldfish")," or have a ",(0,i.mdx)("inlineCode",{parentName:"p"},"feed")," method:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'C where\n example.Parent { child = { name = "Goldfish" }, parent = C } |\n example.Has { class_ = C, has = { method = { name = "feed" }}}\n')),(0,i.mdx)("h2",{id:"arrays"},"Arrays"),(0,i.mdx)("p",null,"When the schema uses an array, we need to be able to write queries that traverse the elements of the array. For example, a common use of an array is to represent the list of declarations in a source file. Our example schema defines the ",(0,i.mdx)("inlineCode",{parentName:"p"},"FileClasses")," predicate:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},"predicate FileClasses :\n {\n file : string,\n classes : [Class]\n }\n")),(0,i.mdx)("p",null,"The goal here is to map efficiently from a filename to the list of classes defined in that file. Suppose we want to write a query that finds all the classes called ",(0,i.mdx)("inlineCode",{parentName:"p"},"Goldfish")," in the file ",(0,i.mdx)("inlineCode",{parentName:"p"},"petshop.example"),", we could do it like this:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'example.FileClasses { file = "petshop.example", classes = Cs };\n{ name = "Goldfish" } = Cs[..]\n')),(0,i.mdx)("p",null,"The second line is the interesting one: ",(0,i.mdx)("inlineCode",{parentName:"p"},'{ name = "Goldfish" } = Cs[..]')," means"),(0,i.mdx)("ul",null,(0,i.mdx)("li",{parentName:"ul"},"on the right-hand side, ",(0,i.mdx)("inlineCode",{parentName:"li"},"Cs[..]")," means \u201ceach element of the array ",(0,i.mdx)("inlineCode",{parentName:"li"},"Cs"),"\u201d"),(0,i.mdx)("li",{parentName:"ul"},"the left-hand side is a pattern, filtering only those ",(0,i.mdx)("inlineCode",{parentName:"li"},"Class")," facts that match ",(0,i.mdx)("inlineCode",{parentName:"li"},'{ name = "Goldfish" }'))),(0,i.mdx)("p",null,"We can also match the whole array with a pattern of the form ",(0,i.mdx)("inlineCode",{parentName:"p"},"[ p1, p2, .. ]")),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> X where [_,X,_] = [1,2,3]\n{ "id": 1040, "key": 2 }\n')),(0,i.mdx)("p",null,"Or if we don't care about the length of the array:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> X where [_,X, ..] = [1,2,3]\n{ "id": 1040, "key": 2 }\n')),(0,i.mdx)("h2",{id:"string-prefix"},"String prefix"),(0,i.mdx)("p",null,"We\u2019ve seen many examples of patterns that match strings. Glean also supports matching strings by ",(0,i.mdx)("em",{parentName:"p"},"prefix"),"; for example:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> example.Class { name = "F".. }\n{ "id": 1026, "key": { "name": "Fish", "line": 30 } }\n')),(0,i.mdx)("p",null,"The syntax ",(0,i.mdx)("inlineCode",{parentName:"p"},'"F"..')," means ",(0,i.mdx)("em",{parentName:"p"},"strings beginning with the prefix")," ",(0,i.mdx)("inlineCode",{parentName:"p"},'\u201dF"'),"."),(0,i.mdx)("admonition",{type:"note"},(0,i.mdx)("p",{parentName:"admonition"},"Why only prefix and not substring matching in general? Prefix matching can be supported efficiently by Glean\u2019s prefix-tree representation of the fact database. Other kinds of string matching could be supported, but they wouldn\u2019t be able to exploit the database representation so there\u2019s little advantage to implementing them in Angle compared with filtering on the client-side.")),(0,i.mdx)("h2",{id:"tuples"},"Tuples"),(0,i.mdx)("p",null,"A ",(0,i.mdx)("em",{parentName:"p"},"tuple")," is just a a way of writing a record without the field names. So for example, instead of"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre"},"example.Parent { child = C }\n")),(0,i.mdx)("p",null,"we could write"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre"},"example.Parent { C, _ }\n")),(0,i.mdx)("p",null,"When using a tuple you have to list ",(0,i.mdx)("em",{parentName:"p"},"all")," the fields, in the same order as they are declared in the schema. That's why ",(0,i.mdx)("inlineCode",{parentName:"p"},"{ child = C }")," becomes ",(0,i.mdx)("inlineCode",{parentName:"p"},"{ C, _ }")," when written as a tuple."),(0,i.mdx)("p",null,"There are upsides and downsides to using the tuple notation:"),(0,i.mdx)("ul",null,(0,i.mdx)("li",{parentName:"ul"},"Pro: more concise"),(0,i.mdx)("li",{parentName:"ul"},"Con: brittle and sensitive to changes in the schema. If we add a field, then tuple patterns will break whereas record patterns won't.")),(0,i.mdx)("p",null,'As a rule of thumb we tend to use tuple syntax in cases where the predicate is "obviously" a relation, such as ',(0,i.mdx)("inlineCode",{parentName:"p"},"example.Parent"),", but we wouldn't use tuple syntax for more complex records."),(0,i.mdx)("h2",{id:"enums-and-bool"},"Enums and bool"),(0,i.mdx)("p",null,"An ",(0,i.mdx)("inlineCode",{parentName:"p"},"enum")," type is a set of named constants. In the ",(0,i.mdx)("inlineCode",{parentName:"p"},"Has")," predicate we used an ",(0,i.mdx)("inlineCode",{parentName:"p"},"enum")," type to indicate whether a class member is ",(0,i.mdx)("inlineCode",{parentName:"p"},"Public")," or ",(0,i.mdx)("inlineCode",{parentName:"p"},"Private"),":"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},"predicate Has :\n {\n class_ : Class,\n has : Member,\n access : enum { Public | Private },\n }\n")),(0,i.mdx)("p",null,"To match an ",(0,i.mdx)("inlineCode",{parentName:"p"},"enum")," we just use the appropriate identifier, in this case ",(0,i.mdx)("inlineCode",{parentName:"p"},"Public")," or ",(0,i.mdx)("inlineCode",{parentName:"p"},"Private"),":"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> example.Has { access = Private }\n{ "id": 1036, "key": { "class_": { "id": 1026 }, "has": { "id": 1035 }, "access": 1 } }\n')),(0,i.mdx)("p",null,"Note that in the JSON format results, an ",(0,i.mdx)("inlineCode",{parentName:"p"},"enum")," is represented by an integer. When you make queries in code, the ",(0,i.mdx)("inlineCode",{parentName:"p"},"enum")," will be represented by an appropriate type, such as a ",(0,i.mdx)("inlineCode",{parentName:"p"},"data")," type in Haskell."),(0,i.mdx)("p",null,"The boolean type ",(0,i.mdx)("inlineCode",{parentName:"p"},"bool")," is a special case of an ",(0,i.mdx)("inlineCode",{parentName:"p"},"enum"),", defined like this:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},"type bool = enum { false | true }\n")),(0,i.mdx)("h2",{id:"negation"},"Negation"),(0,i.mdx)("p",null,"If we want results that do not match a certain criterion, we can use ",(0,i.mdx)("inlineCode",{parentName:"p"},"!")," to\nspecify a subquery that should fail. A subquery fails if it doesn't return any\nresult."),(0,i.mdx)("p",null,"For example, we can find classes that don't have methods"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> C where C = example.Class _; !(example.Has { class_ = C, has = { method = _ } })\n{ "id": 1026, "key": { "name": "Fish", "line": 30 } }\n{ "id": 1027, "key": { "name": "Goldfish", "line": 40 } }\n{ "id": 1025, "key": { "name": "Lizard", "line": 20 } }\n')),(0,i.mdx)("p",null,"Or we could find the maximum element in an array"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> X where Values = [5,1,2,3]; X = Values[..]; !(Y = Values[..]; Y > X);\n{ "id": 1091, "key": 5 }\n')),(0,i.mdx)("p",null,"The query asks for the ",(0,i.mdx)("inlineCode",{parentName:"p"},"X")," for which given all values of ",(0,i.mdx)("inlineCode",{parentName:"p"},"Y")," ",(0,i.mdx)("em",{parentName:"p"},"none")," is greater\nthan it. If ",(0,i.mdx)("inlineCode",{parentName:"p"},"Y = Values[..]")," were outside of the negation, the meaning would\nbe give me all ",(0,i.mdx)("inlineCode",{parentName:"p"},"X")," for which there is ",(0,i.mdx)("em",{parentName:"p"},"at least one")," ",(0,i.mdx)("inlineCode",{parentName:"p"},"Y")," that is not greater\nthan it. The answer to that would be all elements."))}c.isMDXComponent=!0},47596:function(e,n,a){var t=this&&this.__awaiter||function(e,n,a,t){return new(a||(a=Promise))((function(i,l){function r(e){try{o(t.next(e))}catch(n){l(n)}}function s(e){try{o(t.throw(e))}catch(n){l(n)}}function o(e){var n;e.done?i(e.value):(n=e.value,n instanceof a?n:new a((function(e){e(n)}))).then(r,s)}o((t=t.apply(e,n||[])).next())}))};Object.defineProperty(n,"__esModule",{value:!0}),n.getSpecInfo=void 0;const i=a(11737);n.getSpecInfo=function(e){return t(this,void 0,void 0,(function*(){return yield i.call({module:"bloks",api:"getSpecInfo",args:{styleId:e}})}))}},11737:function(e,n){var a=this&&this.__awaiter||function(e,n,a,t){return new(a||(a=Promise))((function(i,l){function r(e){try{o(t.next(e))}catch(n){l(n)}}function s(e){try{o(t.throw(e))}catch(n){l(n)}}function o(e){var n;e.done?i(e.value):(n=e.value,n instanceof a?n:new a((function(e){e(n)}))).then(r,s)}o((t=t.apply(e,n||[])).next())}))};Object.defineProperty(n,"__esModule",{value:!0}),n.call=void 0;let t=!1,i=0;const l={};n.call=function(e){return a(this,void 0,void 0,(function*(){if("staticdocs.thefacebook.com"!==window.location.hostname&&"localhost"!==window.location.hostname)return Promise.reject(new Error("Not running on static docs"));t||(t=!0,window.addEventListener("message",(e=>{if("static-docs-bridge-response"!==e.data.event)return;const n=e.data.id;n in l||console.error(`Recieved response for id: ${n} with no matching receiver`),"response"in e.data?l[n].resolve(e.data.response):l[n].reject(new Error(e.data.error)),delete l[n]})));const n=i++,a=new Promise(((e,a)=>{l[n]={resolve:e,reject:a}})),r={event:"static-docs-bridge-call",id:n,module:e.module,api:e.api,args:e.args},s="localhost"===window.location.hostname?"*":"https://www.internalfb.com";return window.parent.postMessage(r,s),a}))}},24855:function(e,n,a){var t=this&&this.__awaiter||function(e,n,a,t){return new(a||(a=Promise))((function(i,l){function r(e){try{o(t.next(e))}catch(n){l(n)}}function s(e){try{o(t.throw(e))}catch(n){l(n)}}function o(e){var n;e.done?i(e.value):(n=e.value,n instanceof a?n:new a((function(e){e(n)}))).then(r,s)}o((t=t.apply(e,n||[])).next())}))};Object.defineProperty(n,"__esModule",{value:!0}),n.reportFeatureUsage=n.reportContentCopied=void 0;const i=a(11737);n.reportContentCopied=function(e){return t(this,void 0,void 0,(function*(){const{textContent:n}=e;try{yield i.call({module:"feedback",api:"reportContentCopied",args:{textContent:n}})}catch(a){}}))},n.reportFeatureUsage=function(e){return t(this,void 0,void 0,(function*(){const{featureName:n,id:a}=e;console.log("used feature");try{yield i.call({module:"feedback",api:"reportFeatureUsage",args:{featureName:n,id:a}})}catch(t){}}))}},44256:function(e,n,a){var t=this&&this.__createBinding||(Object.create?function(e,n,a,t){void 0===t&&(t=a),Object.defineProperty(e,t,{enumerable:!0,get:function(){return n[a]}})}:function(e,n,a,t){void 0===t&&(t=a),e[t]=n[a]}),i=this&&this.__setModuleDefault||(Object.create?function(e,n){Object.defineProperty(e,"default",{enumerable:!0,value:n})}:function(e,n){e.default=n}),l=this&&this.__importStar||function(e){if(e&&e.__esModule)return e;var n={};if(null!=e)for(var a in e)"default"!==a&&Object.prototype.hasOwnProperty.call(e,a)&&t(n,e,a);return i(n,e),n};Object.defineProperty(n,"__esModule",{value:!0}),n.OssOnly=n.FbInternalOnly=n.getEphemeralDiffNumber=n.hasEphemeralDiffNumber=n.isInternal=n.validateFbContentArgs=n.fbInternalOnly=n.fbContent=n.inpageeditor=n.feedback=n.uidocs=n.bloks=void 0,n.bloks=l(a(47596)),n.uidocs=l(a(17483)),n.feedback=l(a(24855)),n.inpageeditor=l(a(27312));const r=["internal","external"];function s(e){return d(e),m()?"internal"in e?o(e.internal):[]:"external"in e?o(e.external):[]}function o(e){return"function"==typeof e?e():e}function d(e){if("object"!=typeof e)throw new Error(`fbContent() args must be an object containing keys: ${r}. Instead got ${e}`);if(!Object.keys(e).find((e=>r.find((n=>n===e)))))throw new Error(`No valid args found in ${JSON.stringify(e)}. Accepted keys: ${r}`);const n=Object.keys(e).filter((e=>!r.find((n=>n===e))));if(n.length>0)throw new Error(`Unexpected keys ${n} found in fbContent() args. Accepted keys: ${r}`)}function m(){try{return Boolean(!1)}catch(e){return console.log("process.env.FB_INTERNAL couldn't be read, maybe you forgot to add the required webpack EnvironmentPlugin config?",e),!1}}function p(){try{return null}catch(e){return console.log("process.env.PHABRICATOR_DIFF_NUMBER couldn't be read, maybe you forgot to add the required webpack EnvironmentPlugin config?",e),null}}n.fbContent=s,n.fbInternalOnly=function(e){return s({internal:e})},n.validateFbContentArgs=d,n.isInternal=m,n.hasEphemeralDiffNumber=function(){return Boolean(p())},n.getEphemeralDiffNumber=p,n.FbInternalOnly=function(e){return m()?e.children:null},n.OssOnly=function(e){return m()?null:e.children}},27312:function(e,n,a){var t=this&&this.__awaiter||function(e,n,a,t){return new(a||(a=Promise))((function(i,l){function r(e){try{o(t.next(e))}catch(n){l(n)}}function s(e){try{o(t.throw(e))}catch(n){l(n)}}function o(e){var n;e.done?i(e.value):(n=e.value,n instanceof a?n:new a((function(e){e(n)}))).then(r,s)}o((t=t.apply(e,n||[])).next())}))};Object.defineProperty(n,"__esModule",{value:!0}),n.submitDiff=void 0;const i=a(11737);n.submitDiff=function(e){return t(this,void 0,void 0,(function*(){const{file_path:n,new_content:a,project_name:t,diff_number:l}=e;try{return yield i.call({module:"inpageeditor",api:"createPhabricatorDiffApi",args:{file_path:n,new_content:a,project_name:t,diff_number:l}})}catch(r){throw new Error(`Error occurred while trying to submit diff. Stack trace: ${r}`)}}))}},17483:function(e,n,a){var t=this&&this.__awaiter||function(e,n,a,t){return new(a||(a=Promise))((function(i,l){function r(e){try{o(t.next(e))}catch(n){l(n)}}function s(e){try{o(t.throw(e))}catch(n){l(n)}}function o(e){var n;e.done?i(e.value):(n=e.value,n instanceof a?n:new a((function(e){e(n)}))).then(r,s)}o((t=t.apply(e,n||[])).next())}))};Object.defineProperty(n,"__esModule",{value:!0}),n.getApi=n.docsets=void 0;const i=a(11737);n.docsets={BLOKS_CORE:"887372105406659"},n.getApi=function(e){return t(this,void 0,void 0,(function*(){const{name:n,framework:a,docset:t}=e;return yield i.call({module:"uidocs",api:"getApi",args:{name:n,framework:a,docset:t}})}))}}}]); \ No newline at end of file +"use strict";(self.webpackChunkwebsite=self.webpackChunkwebsite||[]).push([[3627],{3905:(e,n,a)=>{a.r(n),a.d(n,{MDXContext:()=>d,MDXProvider:()=>c,mdx:()=>f,useMDXComponents:()=>p,withMDXComponents:()=>m});var t=a(67294);function i(e,n,a){return n in e?Object.defineProperty(e,n,{value:a,enumerable:!0,configurable:!0,writable:!0}):e[n]=a,e}function l(){return l=Object.assign||function(e){for(var n=1;n=0||(i[a]=e[a]);return i}(e,n);if(Object.getOwnPropertySymbols){var l=Object.getOwnPropertySymbols(e);for(t=0;t=0||Object.prototype.propertyIsEnumerable.call(e,a)&&(i[a]=e[a])}return i}var d=t.createContext({}),m=function(e){return function(n){var a=p(n.components);return t.createElement(e,l({},n,{components:a}))}},p=function(e){var n=t.useContext(d),a=n;return e&&(a="function"==typeof e?e(n):s(s({},n),e)),a},c=function(e){var n=p(e.components);return t.createElement(d.Provider,{value:n},e.children)},u={inlineCode:"code",wrapper:function(e){var n=e.children;return t.createElement(t.Fragment,{},n)}},h=t.forwardRef((function(e,n){var a=e.components,i=e.mdxType,l=e.originalType,r=e.parentName,d=o(e,["components","mdxType","originalType","parentName"]),m=p(a),c=i,h=m["".concat(r,".").concat(c)]||m[c]||u[c]||l;return a?t.createElement(h,s(s({ref:n},d),{},{components:a})):t.createElement(h,s({ref:n},d))}));function f(e,n){var a=arguments,i=n&&n.mdxType;if("string"==typeof e||i){var l=a.length,r=new Array(l);r[0]=h;var s={};for(var o in n)hasOwnProperty.call(n,o)&&(s[o]=n[o]);s.originalType=e,s.mdxType="string"==typeof e?e:i,r[1]=s;for(var d=2;d{a.r(n),a.d(n,{assets:()=>d,contentTitle:()=>s,default:()=>c,frontMatter:()=>r,metadata:()=>o,toc:()=>m});var t=a(83117),i=(a(67294),a(3905)),l=a(44256);const r={id:"guide",title:"Angle Guide",sidebar_label:"Guide"},s=void 0,o={unversionedId:"angle/guide",id:"angle/guide",title:"Angle Guide",description:"The following guide will explain Angle from first principles, leading you through from simple queries to more complex ones.",source:"@site/docs/angle/guide.md",sourceDirName:"angle",slug:"/angle/guide",permalink:"/docs/angle/guide",draft:!1,editUrl:"https://github.com/facebookincubator/Glean/tree/main/glean/website/docs/angle/guide.md",tags:[],version:"current",frontMatter:{id:"guide",title:"Angle Guide",sidebar_label:"Guide"},sidebar:"someSidebar",previous:{title:"Introduction",permalink:"/docs/angle/intro"},next:{title:"Query Efficiency",permalink:"/docs/angle/efficiency"}},d={},m=[{value:"Just the facts",id:"just-the-facts",level:2},{value:"Matching nested facts",id:"matching-nested-facts",level:2},{value:"Union types",id:"union-types",level:2},{value:"Maybe",id:"maybe",level:2},{value:"Or-patterns",id:"or-patterns",level:2},{value:"If-patterns",id:"if-patterns",level:2},{value:"More complex queries",id:"more-complex-queries",level:2},{value:"Statements",id:"statements",level:2},{value:"Arrays",id:"arrays",level:2},{value:"String prefix",id:"string-prefix",level:2},{value:"Tuples",id:"tuples",level:2},{value:"Enums and bool",id:"enums-and-bool",level:2},{value:"Negation",id:"negation",level:2}],p={toc:m};function c(e){let{components:n,...a}=e;return(0,i.mdx)("wrapper",(0,t.Z)({},p,a,{components:n,mdxType:"MDXLayout"}),(0,i.mdx)("p",null,"The following guide will explain Angle from first principles, leading you through from simple queries to more complex ones."),(0,i.mdx)("p",null,"If you want to try the examples for yourself, or experiment with\nchanges to the example schema, you should first follow the\ninstructions in ",(0,i.mdx)("a",{parentName:"p",href:"/docs/walkthrough"},"Walkthrough")," to get set up."),(0,i.mdx)(l.FbInternalOnly,{mdxType:"FbInternalOnly"},(0,i.mdx)("p",null,"There are also ",(0,i.mdx)("a",{parentName:"p",href:"https://www.internalfb.com/intern/wiki/Glean/Query/Angle/Angle_examples/"},"examples of using Angle")," to query real data.")),(0,i.mdx)("h2",{id:"just-the-facts"},"Just the facts"),(0,i.mdx)("p",null,"Data in Glean is described by a ",(0,i.mdx)("em",{parentName:"p"},"schema"),", which we normally put in a file with the extension ",(0,i.mdx)("inlineCode",{parentName:"p"},"angle"),". For the purposes of this guide we\u2019ll use the example schema in ",(0,i.mdx)("inlineCode",{parentName:"p"},"example.angle"),". Full details about defining schemas can be found in ",(0,i.mdx)("a",{parentName:"p",href:"/docs/schema/basic"},"Schemas"),". The ",(0,i.mdx)("inlineCode",{parentName:"p"},"example.angle")," file contains a schema definition like this:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},"schema example.1 {\n\n# definitions go here\n\n}\n")),(0,i.mdx)("p",null,"This says we\u2019re defining a schema called ",(0,i.mdx)("inlineCode",{parentName:"p"},"example"),", with version 1."),(0,i.mdx)("p",null,"The schema contains definitions for ",(0,i.mdx)("em",{parentName:"p"},"predicates"),". A predicate is the type of ",(0,i.mdx)("em",{parentName:"p"},"facts"),", which are the individual pieces of information that Glean stores. Our example schema models a simplified class hierarchy for an object-oriented language, starting with a predicate for a ",(0,i.mdx)("inlineCode",{parentName:"p"},"Class"),":"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},"predicate Class :\n {\n name : string,\n line : nat,\n }\n")),(0,i.mdx)("p",null,"This says that the facts of ",(0,i.mdx)("inlineCode",{parentName:"p"},"Class")," are records with two fields, a ",(0,i.mdx)("inlineCode",{parentName:"p"},"name")," field which contains a ",(0,i.mdx)("inlineCode",{parentName:"p"},"string"),", and a ",(0,i.mdx)("inlineCode",{parentName:"p"},"line")," field which contains a ",(0,i.mdx)("inlineCode",{parentName:"p"},"nat")," (\u201cnat\u201d is short for \u201cnatural number\u201d, which is limited to 64 bits in Glean)."),(0,i.mdx)("p",null,"The simplest type of Angle query is one that just selects facts from\nthe database that match a pattern. For our first Angle query, let\u2019s\nfind a class by its name:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre"},'facts> example.Class { name = "Pet" }\n{ "id": 1024, "key": { "name": "Pet", "line": 10 } }\n\n1 results, 1 facts, 4.61ms, 117632 bytes, 677 compiled bytes\n')),(0,i.mdx)("p",null,"(The last line contains statistics about query performance from Glean; I\u2019ll leave this out in the rest of the examples.)"),(0,i.mdx)("p",null,"What\u2019s going on here?"),(0,i.mdx)("ul",null,(0,i.mdx)("li",{parentName:"ul"},"The query consists of the ",(0,i.mdx)("em",{parentName:"li"},"predicate name")," ",(0,i.mdx)("inlineCode",{parentName:"li"},"example.Class")," followed by a ",(0,i.mdx)("em",{parentName:"li"},"pattern")," ",(0,i.mdx)("inlineCode",{parentName:"li"},'{ name = "Pet" }')),(0,i.mdx)("li",{parentName:"ul"},"Note that when we refer to a predicate in a query, the name is ",(0,i.mdx)("em",{parentName:"li"},"qualified")," by prefixing the schema name, so it\u2019s ",(0,i.mdx)("inlineCode",{parentName:"li"},"example.Class")," rather than just ",(0,i.mdx)("inlineCode",{parentName:"li"},"Class"),"."),(0,i.mdx)("li",{parentName:"ul"},"The query returns all the facts of ",(0,i.mdx)("inlineCode",{parentName:"li"},"example.Class")," that match the pattern")),(0,i.mdx)("p",null,"The shell shows results in JSON format. When you\u2019re making Glean\nqueries from code, the results will normally be decoded into native\ndata types that you can manipulate directly in whatever language\nyou\u2019re using; for more details see ",(0,i.mdx)("a",{parentName:"p",href:"/docs/schema/thrift"},"Thrift and\nJSON"),"."),(0,i.mdx)("p",null,"Note that each fact has a unique ",(0,i.mdx)("inlineCode",{parentName:"p"},"id"),". This is how Glean identifies facts in its database. As a user you normally won\u2019t have to worry about fact ",(0,i.mdx)("inlineCode",{parentName:"p"},"id"),"s; you can think of them like memory addresses."),(0,i.mdx)("p",null,"The pattern specifies which facts to return. In the example above, our pattern is matching a record type and specifying a subset of the fields: just the ",(0,i.mdx)("inlineCode",{parentName:"p"},"name")," field. We could match the ",(0,i.mdx)("inlineCode",{parentName:"p"},"line")," field instead:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=sh"},'facts> example.Class { line = 20 }\n{ "id": 1025, "key": { "name": "Lizard", "line": 20 } }\n')),(0,i.mdx)("admonition",{type:"note"},(0,i.mdx)("p",{parentName:"admonition"},"Your patterns should normally match fields at the ",(0,i.mdx)("em",{parentName:"p"},"beginning")," of the\nrecord, because facts in the database are indexed by a prefix of the\nfields. Matching a field in the middle of the record works by scanning\nall the facts, which could be expensive. We\u2019ll get into this in more\ndetail in ",(0,i.mdx)("a",{parentName:"p",href:"/docs/angle/efficiency"},"Query Efficiency"),".")),(0,i.mdx)("p",null,'What other kinds of patterns can we use? Well, the simplest patterns are the wildcard, \u201c_\u201d, which matches anything, and "never", which always fails to match.'),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> example.Class _\n{ "id": 1026, "key": { "name": "Fish", "line": 30 } }\n{ "id": 1027, "key": { "name": "Goldfish", "line": 40 } }\n{ "id": 1025, "key": { "name": "Lizard", "line": 20 } }\n{ "id": 1024, "key": { "name": "Pet", "line": 10 } }\nfacts> example.Class never\n(no results)\n')),(0,i.mdx)("p",null,"We\u2019ll introduce more kinds of pattern in the following sections. The full list of patterns can be found in ",(0,i.mdx)("a",{parentName:"p",href:"/docs/angle/reference"},"Angle Reference"),"."),(0,i.mdx)("h2",{id:"matching-nested-facts"},"Matching nested facts"),(0,i.mdx)("p",null,"The real power of Glean comes from relationships between facts. Facts can refer directly to other facts, and we can write queries that directly match on these connections."),(0,i.mdx)("p",null,"Our example schema has a predicate that expresses the inheritance relationship between classes:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},"predicate Parent :\n {\n child : Class,\n parent : Class,\n }\n")),(0,i.mdx)("p",null,"Let\u2019s find what ",(0,i.mdx)("inlineCode",{parentName:"p"},"Fish")," inherits from:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> example.Parent { child = { name = "Fish" }}\n{\n "id": 1029,\n "key": { "child": { "id": 1026, "key": { "name": "Fish", "line": 30 } }, "parent": { "id": 1024, "key": { "name": "Pet", "line": 10 } } }\n}\n')),(0,i.mdx)("p",null,"Let\u2019s break this down."),(0,i.mdx)("ul",null,(0,i.mdx)("li",{parentName:"ul"},(0,i.mdx)("inlineCode",{parentName:"li"},'{ child = { name = "Fish" }}')," is a pattern that matches the key type of ",(0,i.mdx)("inlineCode",{parentName:"li"},"Parent")),(0,i.mdx)("li",{parentName:"ul"},"So, looking at the schema, ",(0,i.mdx)("inlineCode",{parentName:"li"},'{ name = "Fish" }')," is a pattern that should match the ",(0,i.mdx)("inlineCode",{parentName:"li"},"Class")," in the field ",(0,i.mdx)("inlineCode",{parentName:"li"},"child"),".")),(0,i.mdx)("p",null,"By default Angle queries recursively expand facts in the results. We can see in the above result that the ",(0,i.mdx)("inlineCode",{parentName:"p"},"child")," and ",(0,i.mdx)("inlineCode",{parentName:"p"},"parent")," fields contain the full facts they point to. If we want the result to be \u201cshallow\u201d, meaning it contains just the facts that match and not the nested facts, we can ask Glean to not expand the content of those references. In the shell this is done by running the command ",(0,i.mdx)("inlineCode",{parentName:"p"},":expand off"),":"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> :expand off\nfacts> example.Parent { child = { name = "Fish" }}\n{ "id": 1029, "key": { "child": { "id": 1026 }, "parent": { "id": 1024 } } }\n')),(0,i.mdx)("p",null,"We can of course go the other way and find all the children of a class:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> example.Parent { parent = { name = "Pet" }}\n{\n "id": 1028,\n "key": {\n "child": { "id": 1025, "key": { "name": "Lizard", "line": 20 } },\n "parent": { "id": 1024, "key": { "name": "Pet", "line": 10 } }\n }\n}\n{\n "id": 1029,\n "key": {\n "child": { "id": 1026, "key": { "name": "Fish", "line": 30 } },\n "parent": { "id": 1024, "key": { "name": "Pet", "line": 10 } }\n }\n}\n')),(0,i.mdx)("p",null,"But as before, note that this would be an inefficient query if we had a lot of data because the pattern is matching on the second field of ",(0,i.mdx)("inlineCode",{parentName:"p"},"Parent")," (namely ",(0,i.mdx)("inlineCode",{parentName:"p"},"parent"),"). Later we\u2019ll see how to make these queries more efficient using a derived predicate."),(0,i.mdx)("h2",{id:"union-types"},"Union types"),(0,i.mdx)("p",null,"Our examples so far have dealt with record types. Glean also supports ",(0,i.mdx)("em",{parentName:"p"},"union types"),", also called ",(0,i.mdx)("em",{parentName:"p"},"sum types"),", which are used to express multiple alternatives. For example, let\u2019s expand our schema to include class members which can be either a method or a variable:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},"predicate Has :\n {\n class_ : Class,\n has : Member,\n access : enum { Public | Private },\n }\n\npredicate Member :\n {\n method : { name : string, doc : maybe string } |\n variable : { name : string }\n }\n}\n")),(0,i.mdx)("p",null,"The predicate ",(0,i.mdx)("inlineCode",{parentName:"p"},"Has")," maps a ",(0,i.mdx)("inlineCode",{parentName:"p"},"Class")," to a ",(0,i.mdx)("inlineCode",{parentName:"p"},"Member")," (with a ",(0,i.mdx)("inlineCode",{parentName:"p"},"Public")," or ",(0,i.mdx)("inlineCode",{parentName:"p"},"Private")," annotation), and a ",(0,i.mdx)("inlineCode",{parentName:"p"},"Member")," is either ",(0,i.mdx)("inlineCode",{parentName:"p"},"method")," or ",(0,i.mdx)("inlineCode",{parentName:"p"},"variable"),", with some associated data. Note that a ",(0,i.mdx)("inlineCode",{parentName:"p"},"Class")," might have more than one ",(0,i.mdx)("inlineCode",{parentName:"p"},"Member"),", which is fine: there can be multiple ",(0,i.mdx)("inlineCode",{parentName:"p"},"Has")," facts for a given ",(0,i.mdx)("inlineCode",{parentName:"p"},"Class"),"."),(0,i.mdx)("admonition",{type:"note"},(0,i.mdx)("p",{parentName:"admonition"},"The schema uses ",(0,i.mdx)("inlineCode",{parentName:"p"},"class_")," rather than ",(0,i.mdx)("inlineCode",{parentName:"p"},"class")," as a field name, because ",(0,i.mdx)("inlineCode",{parentName:"p"},"class")," is a reserved word in Angle. There are many such reserved words, which are reserved not because Angle uses them, but because they cause problems for code that is automatically generated from the schema. To avoid having too many ad-hoc language-specific naming rules, Glean prevents certain problematic names from being used in the schema. The Angle compiler will tell you if you try to use a reserved word.")),(0,i.mdx)("p",null,"Let\u2019s find classes that have a variable called ",(0,i.mdx)("inlineCode",{parentName:"p"},"fins"),":"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> example.Has { has = { variable = { name = "fins" }}}\n{\n "id": 1036,\n "key": {\n "class_": { "id": 1026, "key": { "name": "Fish", "line": 30 } },\n "has": { "id": 1035, "key": { "variable": { "name": "fins" } } },\n "access": 1\n }\n}\n')),(0,i.mdx)("p",null,"The key thing here is that we matched on ",(0,i.mdx)("inlineCode",{parentName:"p"},"Member")," which is a union type, using the pattern ",(0,i.mdx)("inlineCode",{parentName:"p"},'{ variable = { name = "fins" }}'),". A pattern to match a union type looks very much like a record pattern, but it can have only a single field, in this case either ",(0,i.mdx)("inlineCode",{parentName:"p"},"variable")," or ",(0,i.mdx)("inlineCode",{parentName:"p"},"method"),"."),(0,i.mdx)("h2",{id:"maybe"},"Maybe"),(0,i.mdx)("p",null,"Glean has one built-in union type called ",(0,i.mdx)("inlineCode",{parentName:"p"},"maybe"),", which is useful when we want to have optional values in the data. It's used in our example schema to attach optional documentation to a class member:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},"predicate Member :\n {\n method : { name : string, doc : maybe string } |\n variable : { name : string }\n }\n")),(0,i.mdx)("p",null,"The type ",(0,i.mdx)("inlineCode",{parentName:"p"},"maybe string")," behaves exactly as if it were defined as the union type ",(0,i.mdx)("inlineCode",{parentName:"p"},"{ nothing | just : string }"),". That means we can write a pattern that matches it, exactly as we would write a pattern for ",(0,i.mdx)("inlineCode",{parentName:"p"},"{ nothing | just : string }"),":"),(0,i.mdx)("p",null,"Methods without documentation:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre"},"facts> example.Member { method = { doc = nothing } }\n")),(0,i.mdx)("p",null,"Methods with documentation:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre"},"facts> example.Member { method = { doc = { just = _ }}}\n")),(0,i.mdx)("h2",{id:"or-patterns"},"Or-patterns"),(0,i.mdx)("p",null,"In a pattern we can express multiple alternatives by separating patterns with a vertical bar ",(0,i.mdx)("inlineCode",{parentName:"p"},"|"),"."),(0,i.mdx)("p",null,"For example, we can find classes on lines 20 or 30:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> example.Class { line = 20 | 30 }\n{ "id": 1025, "key": { "name": "Lizard", "line": 20 } }\n{ "id": 1026, "key": { "name": "Fish", "line": 30 } }\n')),(0,i.mdx)("p",null,"Or we can find all the classes that have either a ",(0,i.mdx)("inlineCode",{parentName:"p"},"method")," called ",(0,i.mdx)("inlineCode",{parentName:"p"},"feed")," or a ",(0,i.mdx)("inlineCode",{parentName:"p"},"variable")," with any name:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> example.Has { has = { method = { name = "feed" }} | { variable = _ }}\n\n(results omitted)\n')),(0,i.mdx)("h2",{id:"if-patterns"},"If-patterns"),(0,i.mdx)("p",null,"We can conditionally match patterns using ",(0,i.mdx)("inlineCode",{parentName:"p"},"if then else"),"."),(0,i.mdx)("p",null,"Variables matched in the condition will be available in the ",(0,i.mdx)("inlineCode",{parentName:"p"},"then")," branch."),(0,i.mdx)("p",null,"Whilst an or-pattern will always evaluate both of its branches, the ",(0,i.mdx)("inlineCode",{parentName:"p"},"else")," branch of an if-pattern will\nnever be evaluated if the condition succeeds at least once."),(0,i.mdx)("p",null,"For example, we could get all child classes if inheritance is being used in the codebase, or\nretrieve all classes if it isn't."),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre"},'facts > if (example.Parent { child = X }) then X else example.Class _\n { "id": 1025, "key": { "name": "Lizard", "line": 20 } }\n { "id": 1026, "key": { "name": "Fish", "line": 30 } }\n { "id": 1027, "key": { "name": "Goldfish", "line": 40 } }\n')),(0,i.mdx)("p",null,"Please note that if-patterns cannot be used in stored derived predicates. This\nis the case because they require the use of negation, which is disallowed in\nstored predicates."),(0,i.mdx)("h2",{id:"more-complex-queries"},"More complex queries"),(0,i.mdx)("p",null,"So far we\u2019ve seen how to query for facts by matching patterns, including matching nested facts. In this section we\u2019ll see how to construct more complex queries that combine matching facts from multiple predicates."),(0,i.mdx)("p",null,"Suppose we want to find all the parents of classes that have a variable called ",(0,i.mdx)("inlineCode",{parentName:"p"},"fins"),". We need to build a query that will"),(0,i.mdx)("ul",null,(0,i.mdx)("li",{parentName:"ul"},"find the classes with a variable called ",(0,i.mdx)("inlineCode",{parentName:"li"},"fins")," using ",(0,i.mdx)("inlineCode",{parentName:"li"},"example.Has")," as we did above"),(0,i.mdx)("li",{parentName:"ul"},"find their parents using ",(0,i.mdx)("inlineCode",{parentName:"li"},"example.Parent"))),(0,i.mdx)("p",null,"We can combine these two as follows:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'example.Has\n {\n class_ = C,\n has = { variable = { name = "fins" }}\n };\nexample.Parent { child = C }\n')),(0,i.mdx)("admonition",{type:"note"},(0,i.mdx)("p",{parentName:"admonition"},"I\u2019ve written this on several lines with indentation to illustrate it\nbetter, to do this in the shell you will need to use the ",(0,i.mdx)("inlineCode",{parentName:"p"},":edit"),"\ncommand to put the query in a temporary file.")),(0,i.mdx)("p",null,"The key thing here is that we used a ",(0,i.mdx)("em",{parentName:"p"},"variable")," ",(0,i.mdx)("inlineCode",{parentName:"p"},"C")," to stand for the ",(0,i.mdx)("inlineCode",{parentName:"p"},"class_")," field when matching facts of ",(0,i.mdx)("inlineCode",{parentName:"p"},"example.Has"),", and then we searched for ",(0,i.mdx)("inlineCode",{parentName:"p"},"example.Parent")," facts with the same value of ",(0,i.mdx)("inlineCode",{parentName:"p"},"C")," for the ",(0,i.mdx)("inlineCode",{parentName:"p"},"child")," field."),(0,i.mdx)("p",null,"Note that variables must ",(0,i.mdx)("em",{parentName:"p"},"always")," begin with an upper-case letter, while schema names (",(0,i.mdx)("inlineCode",{parentName:"p"},"example)")," and field names (",(0,i.mdx)("inlineCode",{parentName:"p"},"child"),") begin with a lower-case letter."),(0,i.mdx)("p",null,"The semicolon separates multiple ",(0,i.mdx)("em",{parentName:"p"},"statements")," in a query. When there are multiple statements the results of the query are the facts that match the last statement, in this case the ",(0,i.mdx)("inlineCode",{parentName:"p"},"example.Parent"),". Let\u2019s try it:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> example.Has { class_ = C, has = { variable = { name = "fins" }}}; example.Parent { child = C }\n{\n "id": 1029,\n "key": {\n "child": { "id": 1026, "key": { "name": "Fish", "line": 30 } },\n "parent": { "id": 1024, "key": { "name": "Pet", "line": 10 } }\n }\n}\n')),(0,i.mdx)("p",null," Suppose we don\u2019t care too much about the child here, we only care about getting a list of the parents. We can avoid returning the redundant information by specifying explicitly what it is we want to return from the query:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'P where\n example.Has\n {\n class_ = C,\n has = { variable = { name = "fins" }}\n };\n example.Parent { child = C, parent = P }\n')),(0,i.mdx)("p",null,"The general form of the query is ",(0,i.mdx)("em",{parentName:"p"},(0,i.mdx)("inlineCode",{parentName:"em"},"expression"))," ",(0,i.mdx)("inlineCode",{parentName:"p"},"where")," ",(0,i.mdx)("em",{parentName:"p"},(0,i.mdx)("inlineCode",{parentName:"em"},"statements")),", where ",(0,i.mdx)("em",{parentName:"p"},(0,i.mdx)("inlineCode",{parentName:"em"},"expression"))," is an arbitrary expression and each statement is a pattern that matches some facts. The results of the query are the distinct values of ",(0,i.mdx)("em",{parentName:"p"},(0,i.mdx)("inlineCode",{parentName:"em"},"expression"))," for which all the statements match facts in the database."),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> P where example.Has { class_ = C, has = { variable = { name = "fins" }}}; example.Parent { child = C, parent = P }\n{ "id": 1024, "key": { "name": "Pet", "line": 10 } }\n')),(0,i.mdx)("h2",{id:"statements"},"Statements"),(0,i.mdx)("p",null,"In general, a statement can be of the form ",(0,i.mdx)("em",{parentName:"p"},"A = B.")," For example, if we write"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'C = example.Class { name = "Fish" };\nexample.Parent { child = C }\n')),(0,i.mdx)("p",null,"that\u2019s the same as"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'example.Parent { child = { name = "Fish" }}\n')),(0,i.mdx)("p",null,"A statement can have a pattern on either side, for example"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'C where\n C = example.Class { name = N };\n N = "Fish" | "Goldfish"\n')),(0,i.mdx)("p",null,"A statement can itself be a set of alternatives separated by a vertical bar ",(0,i.mdx)("inlineCode",{parentName:"p"},"|"),". For example, we can find classes that are either a parent of the ",(0,i.mdx)("inlineCode",{parentName:"p"},"Goldfish")," or have a ",(0,i.mdx)("inlineCode",{parentName:"p"},"feed")," method:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'C where\n example.Parent { child = { name = "Goldfish" }, parent = C } |\n example.Has { class_ = C, has = { method = { name = "feed" }}}\n')),(0,i.mdx)("h2",{id:"arrays"},"Arrays"),(0,i.mdx)("p",null,"When the schema uses an array, we need to be able to write queries that traverse the elements of the array. For example, a common use of an array is to represent the list of declarations in a source file. Our example schema defines the ",(0,i.mdx)("inlineCode",{parentName:"p"},"FileClasses")," predicate:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},"predicate FileClasses :\n {\n file : string,\n classes : [Class]\n }\n")),(0,i.mdx)("p",null,"The goal here is to map efficiently from a filename to the list of classes defined in that file. Suppose we want to write a query that finds all the classes called ",(0,i.mdx)("inlineCode",{parentName:"p"},"Goldfish")," in the file ",(0,i.mdx)("inlineCode",{parentName:"p"},"petshop.example"),", we could do it like this:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'example.FileClasses { file = "petshop.example", classes = Cs };\n{ name = "Goldfish" } = Cs[..]\n')),(0,i.mdx)("p",null,"The second line is the interesting one: ",(0,i.mdx)("inlineCode",{parentName:"p"},'{ name = "Goldfish" } = Cs[..]')," means"),(0,i.mdx)("ul",null,(0,i.mdx)("li",{parentName:"ul"},"on the right-hand side, ",(0,i.mdx)("inlineCode",{parentName:"li"},"Cs[..]")," means \u201ceach element of the array ",(0,i.mdx)("inlineCode",{parentName:"li"},"Cs"),"\u201d"),(0,i.mdx)("li",{parentName:"ul"},"the left-hand side is a pattern, filtering only those ",(0,i.mdx)("inlineCode",{parentName:"li"},"Class")," facts that match ",(0,i.mdx)("inlineCode",{parentName:"li"},'{ name = "Goldfish" }'))),(0,i.mdx)("p",null,"We can also match the whole array with a pattern of the form ",(0,i.mdx)("inlineCode",{parentName:"p"},"[ p1, p2, .. ]")),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> X where [_,X,_] = [1,2,3]\n{ "id": 1040, "key": 2 }\n')),(0,i.mdx)("p",null,"Or if we don't care about the length of the array:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> X where [_,X, ..] = [1,2,3]\n{ "id": 1040, "key": 2 }\n')),(0,i.mdx)("h2",{id:"string-prefix"},"String prefix"),(0,i.mdx)("p",null,"We\u2019ve seen many examples of patterns that match strings. Glean also supports matching strings by ",(0,i.mdx)("em",{parentName:"p"},"prefix"),"; for example:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> example.Class { name = "F".. }\n{ "id": 1026, "key": { "name": "Fish", "line": 30 } }\n')),(0,i.mdx)("p",null,"The syntax ",(0,i.mdx)("inlineCode",{parentName:"p"},'"F"..')," means ",(0,i.mdx)("em",{parentName:"p"},"strings beginning with the prefix")," ",(0,i.mdx)("inlineCode",{parentName:"p"},'\u201dF"'),"."),(0,i.mdx)("admonition",{type:"note"},(0,i.mdx)("p",{parentName:"admonition"},"Why only prefix and not substring matching in general? Prefix matching can be supported efficiently by Glean\u2019s prefix-tree representation of the fact database. Other kinds of string matching could be supported, but they wouldn\u2019t be able to exploit the database representation so there\u2019s little advantage to implementing them in Angle compared with filtering on the client-side.")),(0,i.mdx)("h2",{id:"tuples"},"Tuples"),(0,i.mdx)("p",null,"A ",(0,i.mdx)("em",{parentName:"p"},"tuple")," is just a a way of writing a record without the field names. So for example, instead of"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre"},"example.Parent { child = C }\n")),(0,i.mdx)("p",null,"we could write"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre"},"example.Parent { C, _ }\n")),(0,i.mdx)("p",null,"When using a tuple you have to list ",(0,i.mdx)("em",{parentName:"p"},"all")," the fields, in the same order as they are declared in the schema. That's why ",(0,i.mdx)("inlineCode",{parentName:"p"},"{ child = C }")," becomes ",(0,i.mdx)("inlineCode",{parentName:"p"},"{ C, _ }")," when written as a tuple."),(0,i.mdx)("p",null,"There are upsides and downsides to using the tuple notation:"),(0,i.mdx)("ul",null,(0,i.mdx)("li",{parentName:"ul"},"Pro: more concise"),(0,i.mdx)("li",{parentName:"ul"},"Con: brittle and sensitive to changes in the schema. If we add a field, then tuple patterns will break whereas record patterns won't.")),(0,i.mdx)("p",null,'As a rule of thumb we tend to use tuple syntax in cases where the predicate is "obviously" a relation, such as ',(0,i.mdx)("inlineCode",{parentName:"p"},"example.Parent"),", but we wouldn't use tuple syntax for more complex records."),(0,i.mdx)("h2",{id:"enums-and-bool"},"Enums and bool"),(0,i.mdx)("p",null,"An ",(0,i.mdx)("inlineCode",{parentName:"p"},"enum")," type is a set of named constants. In the ",(0,i.mdx)("inlineCode",{parentName:"p"},"Has")," predicate we used an ",(0,i.mdx)("inlineCode",{parentName:"p"},"enum")," type to indicate whether a class member is ",(0,i.mdx)("inlineCode",{parentName:"p"},"Public")," or ",(0,i.mdx)("inlineCode",{parentName:"p"},"Private"),":"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},"predicate Has :\n {\n class_ : Class,\n has : Member,\n access : enum { Public | Private },\n }\n")),(0,i.mdx)("p",null,"To match an ",(0,i.mdx)("inlineCode",{parentName:"p"},"enum")," we just use the appropriate identifier, in this case ",(0,i.mdx)("inlineCode",{parentName:"p"},"Public")," or ",(0,i.mdx)("inlineCode",{parentName:"p"},"Private"),":"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> example.Has { access = Private }\n{ "id": 1036, "key": { "class_": { "id": 1026 }, "has": { "id": 1035 }, "access": 1 } }\n')),(0,i.mdx)("p",null,"Note that in the JSON format results, an ",(0,i.mdx)("inlineCode",{parentName:"p"},"enum")," is represented by an integer. When you make queries in code, the ",(0,i.mdx)("inlineCode",{parentName:"p"},"enum")," will be represented by an appropriate type, such as a ",(0,i.mdx)("inlineCode",{parentName:"p"},"data")," type in Haskell."),(0,i.mdx)("p",null,"The boolean type ",(0,i.mdx)("inlineCode",{parentName:"p"},"bool")," is a special case of an ",(0,i.mdx)("inlineCode",{parentName:"p"},"enum"),", defined like this:"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},"type bool = enum { false | true }\n")),(0,i.mdx)("h2",{id:"negation"},"Negation"),(0,i.mdx)("p",null,"If we want results that do not match a certain criterion, we can use ",(0,i.mdx)("inlineCode",{parentName:"p"},"!")," to\nspecify a subquery that should fail. A subquery fails if it doesn't return any\nresult."),(0,i.mdx)("p",null,"For example, we can find classes that don't have methods"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> C where C = example.Class _; !(example.Has { class_ = C, has = { method = _ } })\n{ "id": 1026, "key": { "name": "Fish", "line": 30 } }\n{ "id": 1027, "key": { "name": "Goldfish", "line": 40 } }\n{ "id": 1025, "key": { "name": "Lizard", "line": 20 } }\n')),(0,i.mdx)("p",null,"Or we could find the maximum element in an array"),(0,i.mdx)("pre",null,(0,i.mdx)("code",{parentName:"pre",className:"language-lang=angle"},'facts> X where Values = [5,1,2,3]; X = Values[..]; !(Y = Values[..]; Y > X)\n{ "id": 1091, "key": 5 }\n')),(0,i.mdx)("p",null,"The query asks for the ",(0,i.mdx)("inlineCode",{parentName:"p"},"X")," for which given all values of ",(0,i.mdx)("inlineCode",{parentName:"p"},"Y")," ",(0,i.mdx)("em",{parentName:"p"},"none")," is greater\nthan it. If ",(0,i.mdx)("inlineCode",{parentName:"p"},"Y = Values[..]")," were outside of the negation, the meaning would\nbe give me all ",(0,i.mdx)("inlineCode",{parentName:"p"},"X")," for which there is ",(0,i.mdx)("em",{parentName:"p"},"at least one")," ",(0,i.mdx)("inlineCode",{parentName:"p"},"Y")," that is not greater\nthan it. The answer to that would be all elements."))}c.isMDXComponent=!0},47596:function(e,n,a){var t=this&&this.__awaiter||function(e,n,a,t){return new(a||(a=Promise))((function(i,l){function r(e){try{o(t.next(e))}catch(n){l(n)}}function s(e){try{o(t.throw(e))}catch(n){l(n)}}function o(e){var n;e.done?i(e.value):(n=e.value,n instanceof a?n:new a((function(e){e(n)}))).then(r,s)}o((t=t.apply(e,n||[])).next())}))};Object.defineProperty(n,"__esModule",{value:!0}),n.getSpecInfo=void 0;const i=a(11737);n.getSpecInfo=function(e){return t(this,void 0,void 0,(function*(){return yield i.call({module:"bloks",api:"getSpecInfo",args:{styleId:e}})}))}},11737:function(e,n){var a=this&&this.__awaiter||function(e,n,a,t){return new(a||(a=Promise))((function(i,l){function r(e){try{o(t.next(e))}catch(n){l(n)}}function s(e){try{o(t.throw(e))}catch(n){l(n)}}function o(e){var n;e.done?i(e.value):(n=e.value,n instanceof a?n:new a((function(e){e(n)}))).then(r,s)}o((t=t.apply(e,n||[])).next())}))};Object.defineProperty(n,"__esModule",{value:!0}),n.call=void 0;let t=!1,i=0;const l={};n.call=function(e){return a(this,void 0,void 0,(function*(){if("staticdocs.thefacebook.com"!==window.location.hostname&&"localhost"!==window.location.hostname)return Promise.reject(new Error("Not running on static docs"));t||(t=!0,window.addEventListener("message",(e=>{if("static-docs-bridge-response"!==e.data.event)return;const n=e.data.id;n in l||console.error(`Recieved response for id: ${n} with no matching receiver`),"response"in e.data?l[n].resolve(e.data.response):l[n].reject(new Error(e.data.error)),delete l[n]})));const n=i++,a=new Promise(((e,a)=>{l[n]={resolve:e,reject:a}})),r={event:"static-docs-bridge-call",id:n,module:e.module,api:e.api,args:e.args},s="localhost"===window.location.hostname?"*":"https://www.internalfb.com";return window.parent.postMessage(r,s),a}))}},24855:function(e,n,a){var t=this&&this.__awaiter||function(e,n,a,t){return new(a||(a=Promise))((function(i,l){function r(e){try{o(t.next(e))}catch(n){l(n)}}function s(e){try{o(t.throw(e))}catch(n){l(n)}}function o(e){var n;e.done?i(e.value):(n=e.value,n instanceof a?n:new a((function(e){e(n)}))).then(r,s)}o((t=t.apply(e,n||[])).next())}))};Object.defineProperty(n,"__esModule",{value:!0}),n.reportFeatureUsage=n.reportContentCopied=void 0;const i=a(11737);n.reportContentCopied=function(e){return t(this,void 0,void 0,(function*(){const{textContent:n}=e;try{yield i.call({module:"feedback",api:"reportContentCopied",args:{textContent:n}})}catch(a){}}))},n.reportFeatureUsage=function(e){return t(this,void 0,void 0,(function*(){const{featureName:n,id:a}=e;console.log("used feature");try{yield i.call({module:"feedback",api:"reportFeatureUsage",args:{featureName:n,id:a}})}catch(t){}}))}},44256:function(e,n,a){var t=this&&this.__createBinding||(Object.create?function(e,n,a,t){void 0===t&&(t=a),Object.defineProperty(e,t,{enumerable:!0,get:function(){return n[a]}})}:function(e,n,a,t){void 0===t&&(t=a),e[t]=n[a]}),i=this&&this.__setModuleDefault||(Object.create?function(e,n){Object.defineProperty(e,"default",{enumerable:!0,value:n})}:function(e,n){e.default=n}),l=this&&this.__importStar||function(e){if(e&&e.__esModule)return e;var n={};if(null!=e)for(var a in e)"default"!==a&&Object.prototype.hasOwnProperty.call(e,a)&&t(n,e,a);return i(n,e),n};Object.defineProperty(n,"__esModule",{value:!0}),n.OssOnly=n.FbInternalOnly=n.getEphemeralDiffNumber=n.hasEphemeralDiffNumber=n.isInternal=n.validateFbContentArgs=n.fbInternalOnly=n.fbContent=n.inpageeditor=n.feedback=n.uidocs=n.bloks=void 0,n.bloks=l(a(47596)),n.uidocs=l(a(17483)),n.feedback=l(a(24855)),n.inpageeditor=l(a(27312));const r=["internal","external"];function s(e){return d(e),m()?"internal"in e?o(e.internal):[]:"external"in e?o(e.external):[]}function o(e){return"function"==typeof e?e():e}function d(e){if("object"!=typeof e)throw new Error(`fbContent() args must be an object containing keys: ${r}. Instead got ${e}`);if(!Object.keys(e).find((e=>r.find((n=>n===e)))))throw new Error(`No valid args found in ${JSON.stringify(e)}. Accepted keys: ${r}`);const n=Object.keys(e).filter((e=>!r.find((n=>n===e))));if(n.length>0)throw new Error(`Unexpected keys ${n} found in fbContent() args. Accepted keys: ${r}`)}function m(){try{return Boolean(!1)}catch(e){return console.log("process.env.FB_INTERNAL couldn't be read, maybe you forgot to add the required webpack EnvironmentPlugin config?",e),!1}}function p(){try{return null}catch(e){return console.log("process.env.PHABRICATOR_DIFF_NUMBER couldn't be read, maybe you forgot to add the required webpack EnvironmentPlugin config?",e),null}}n.fbContent=s,n.fbInternalOnly=function(e){return s({internal:e})},n.validateFbContentArgs=d,n.isInternal=m,n.hasEphemeralDiffNumber=function(){return Boolean(p())},n.getEphemeralDiffNumber=p,n.FbInternalOnly=function(e){return m()?e.children:null},n.OssOnly=function(e){return m()?null:e.children}},27312:function(e,n,a){var t=this&&this.__awaiter||function(e,n,a,t){return new(a||(a=Promise))((function(i,l){function r(e){try{o(t.next(e))}catch(n){l(n)}}function s(e){try{o(t.throw(e))}catch(n){l(n)}}function o(e){var n;e.done?i(e.value):(n=e.value,n instanceof a?n:new a((function(e){e(n)}))).then(r,s)}o((t=t.apply(e,n||[])).next())}))};Object.defineProperty(n,"__esModule",{value:!0}),n.submitDiff=void 0;const i=a(11737);n.submitDiff=function(e){return t(this,void 0,void 0,(function*(){const{file_path:n,new_content:a,project_name:t,diff_number:l}=e;try{return yield i.call({module:"inpageeditor",api:"createPhabricatorDiffApi",args:{file_path:n,new_content:a,project_name:t,diff_number:l}})}catch(r){throw new Error(`Error occurred while trying to submit diff. Stack trace: ${r}`)}}))}},17483:function(e,n,a){var t=this&&this.__awaiter||function(e,n,a,t){return new(a||(a=Promise))((function(i,l){function r(e){try{o(t.next(e))}catch(n){l(n)}}function s(e){try{o(t.throw(e))}catch(n){l(n)}}function o(e){var n;e.done?i(e.value):(n=e.value,n instanceof a?n:new a((function(e){e(n)}))).then(r,s)}o((t=t.apply(e,n||[])).next())}))};Object.defineProperty(n,"__esModule",{value:!0}),n.getApi=n.docsets=void 0;const i=a(11737);n.docsets={BLOKS_CORE:"887372105406659"},n.getApi=function(e){return t(this,void 0,void 0,(function*(){const{name:n,framework:a,docset:t}=e;return yield i.call({module:"uidocs",api:"getApi",args:{name:n,framework:a,docset:t}})}))}}}]); \ No newline at end of file diff --git a/assets/js/runtime~main.ad5399c4.js b/assets/js/runtime~main.67e379df.js similarity index 99% rename from assets/js/runtime~main.ad5399c4.js rename to assets/js/runtime~main.67e379df.js index 67b4b5786..f03ffe4a7 100644 --- a/assets/js/runtime~main.ad5399c4.js +++ b/assets/js/runtime~main.67e379df.js @@ -1 +1 @@ -(()=>{"use strict";var e,a,d,c,f,t={},b={};function r(e){var a=b[e];if(void 0!==a)return a.exports;var d=b[e]={id:e,loaded:!1,exports:{}};return t[e].call(d.exports,d,d.exports,r),d.loaded=!0,d.exports}r.m=t,r.c=b,e=[],r.O=(a,d,c,f)=>{if(!d){var t=1/0;for(i=0;i=f)&&Object.keys(r.O).every((e=>r.O[e](d[o])))?d.splice(o--,1):(b=!1,f0&&e[i-1][2]>f;i--)e[i]=e[i-1];e[i]=[d,c,f]},r.n=e=>{var a=e&&e.__esModule?()=>e.default:()=>e;return r.d(a,{a:a}),a},d=Object.getPrototypeOf?e=>Object.getPrototypeOf(e):e=>e.__proto__,r.t=function(e,c){if(1&c&&(e=this(e)),8&c)return e;if("object"==typeof e&&e){if(4&c&&e.__esModule)return e;if(16&c&&"function"==typeof e.then)return e}var f=Object.create(null);r.r(f);var t={};a=a||[null,d({}),d([]),d(d)];for(var b=2&c&&e;"object"==typeof b&&!~a.indexOf(b);b=d(b))Object.getOwnPropertyNames(b).forEach((a=>t[a]=()=>e[a]));return t.default=()=>e,r.d(f,t),f},r.d=(e,a)=>{for(var d in a)r.o(a,d)&&!r.o(e,d)&&Object.defineProperty(e,d,{enumerable:!0,get:a[d]})},r.f={},r.e=e=>Promise.all(Object.keys(r.f).reduce(((a,d)=>(r.f[d](e,a),a)),[])),r.u=e=>"assets/js/"+({53:"935f2afb",533:"b2b675dd",684:"af94d498",695:"0b5ee478",702:"e72a3ded",734:"f349a764",949:"eb83943b",1218:"2dc45ced",1477:"b2f554cd",1713:"a7023ddc",1953:"3e65d5b4",2535:"814f3328",2597:"373392d9",2642:"a81f2d1d",2731:"473435fa",3089:"a6aa9e1f",3106:"581d6198",3345:"ca95d5ad",3608:"9e4087bc",3627:"7c10977a",3824:"9d050fe4",3827:"37fc9d46",3988:"cfd71120",4013:"01a85c17",4128:"a09c2993",4195:"c4f5d8e4",4224:"5c4c46e6",4282:"31d6d5ed",4338:"41206b0e",4468:"1a20bc57",4648:"d558f29a",4904:"b0b0b448",5307:"af32bd62",5310:"476d6aec",5622:"f228e963",5628:"8293a772",5917:"21418ead",5925:"b8b1253e",5943:"a5dc57e5",6103:"ccc49370",6166:"2dfecbce",6412:"b16bf7d2",6439:"2651e53d",6587:"5e677a75",6910:"27315305",6982:"90f022e0",7023:"31fe93dc",7187:"246b6efd",7586:"d22a0e6a",7698:"abda9da4",7918:"17896441",8325:"33b5e0ca",8490:"6b032a97",8528:"5baf5c08",8610:"6875c492",9357:"391ef999",9403:"cc8d6d7f",9407:"ea32bb6f",9428:"283d7b21",9514:"1be78505",9519:"432e378d",9607:"c83e76ae",9675:"14a2b9f8",9704:"60691868"}[e]||e)+"."+{53:"9119e8a8",533:"37b72b08",684:"e1bf73db",695:"9489cc6b",702:"39d9265d",734:"9a7ac39c",949:"31f84837",1218:"b7bd7c4e",1477:"942e1482",1713:"9e1bdfb8",1953:"48c54bb8",2535:"714d8b90",2597:"29477b3f",2642:"253b6a55",2731:"e9977d9e",3089:"2f29c6cf",3106:"c5e44c63",3345:"fffa9184",3608:"62af1a24",3627:"1d06462e",3824:"382fbf8f",3827:"2c5cec8d",3988:"29a57898",4013:"fc514125",4128:"c3a045a0",4195:"c2e74945",4224:"7eabc49e",4282:"52a7d976",4338:"ced36b31",4468:"07c5b6e2",4648:"624c5a42",4904:"e681fb9f",4972:"c98eee24",5307:"55a39fc6",5310:"efb5df1c",5622:"fa7e970f",5628:"df9f83db",5917:"dcdf8c9d",5925:"3745c099",5943:"cd2b7b08",6103:"ae691c92",6166:"1c4e87bb",6412:"0087e5e1",6439:"6af9bd8e",6587:"081a0151",6910:"edee02ea",6921:"f20e80a2",6982:"16ee69ab",7023:"d080ed08",7187:"013bd076",7586:"e17700ba",7698:"009f7f7a",7918:"cbaf46f4",8325:"a6308c17",8490:"7ec6431f",8528:"6656e233",8610:"6363f22a",9357:"8149209a",9403:"60d7af99",9407:"c7edbf91",9428:"894dddce",9514:"c14ec086",9519:"8e24ccc5",9607:"a7dff9eb",9675:"a113c165",9704:"985278fb"}[e]+".js",r.miniCssF=e=>{},r.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),r.o=(e,a)=>Object.prototype.hasOwnProperty.call(e,a),c={},f="website:",r.l=(e,a,d,t)=>{if(c[e])c[e].push(a);else{var b,o;if(void 0!==d)for(var n=document.getElementsByTagName("script"),i=0;i{b.onerror=b.onload=null,clearTimeout(s);var f=c[e];if(delete c[e],b.parentNode&&b.parentNode.removeChild(b),f&&f.forEach((e=>e(d))),a)return a(d)},s=setTimeout(u.bind(null,void 0,{type:"timeout",target:b}),12e4);b.onerror=u.bind(null,b.onerror),b.onload=u.bind(null,b.onload),o&&document.head.appendChild(b)}},r.r=e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},r.nmd=e=>(e.paths=[],e.children||(e.children=[]),e),r.p="/",r.gca=function(e){return e={17896441:"7918",27315305:"6910",60691868:"9704","935f2afb":"53",b2b675dd:"533",af94d498:"684","0b5ee478":"695",e72a3ded:"702",f349a764:"734",eb83943b:"949","2dc45ced":"1218",b2f554cd:"1477",a7023ddc:"1713","3e65d5b4":"1953","814f3328":"2535","373392d9":"2597",a81f2d1d:"2642","473435fa":"2731",a6aa9e1f:"3089","581d6198":"3106",ca95d5ad:"3345","9e4087bc":"3608","7c10977a":"3627","9d050fe4":"3824","37fc9d46":"3827",cfd71120:"3988","01a85c17":"4013",a09c2993:"4128",c4f5d8e4:"4195","5c4c46e6":"4224","31d6d5ed":"4282","41206b0e":"4338","1a20bc57":"4468",d558f29a:"4648",b0b0b448:"4904",af32bd62:"5307","476d6aec":"5310",f228e963:"5622","8293a772":"5628","21418ead":"5917",b8b1253e:"5925",a5dc57e5:"5943",ccc49370:"6103","2dfecbce":"6166",b16bf7d2:"6412","2651e53d":"6439","5e677a75":"6587","90f022e0":"6982","31fe93dc":"7023","246b6efd":"7187",d22a0e6a:"7586",abda9da4:"7698","33b5e0ca":"8325","6b032a97":"8490","5baf5c08":"8528","6875c492":"8610","391ef999":"9357",cc8d6d7f:"9403",ea32bb6f:"9407","283d7b21":"9428","1be78505":"9514","432e378d":"9519",c83e76ae:"9607","14a2b9f8":"9675"}[e]||e,r.p+r.u(e)},(()=>{var e={1303:0,532:0};r.f.j=(a,d)=>{var c=r.o(e,a)?e[a]:void 0;if(0!==c)if(c)d.push(c[2]);else if(/^(1303|532)$/.test(a))e[a]=0;else{var f=new Promise(((d,f)=>c=e[a]=[d,f]));d.push(c[2]=f);var t=r.p+r.u(a),b=new Error;r.l(t,(d=>{if(r.o(e,a)&&(0!==(c=e[a])&&(e[a]=void 0),c)){var f=d&&("load"===d.type?"missing":d.type),t=d&&d.target&&d.target.src;b.message="Loading chunk "+a+" failed.\n("+f+": "+t+")",b.name="ChunkLoadError",b.type=f,b.request=t,c[1](b)}}),"chunk-"+a,a)}},r.O.j=a=>0===e[a];var a=(a,d)=>{var c,f,t=d[0],b=d[1],o=d[2],n=0;if(t.some((a=>0!==e[a]))){for(c in b)r.o(b,c)&&(r.m[c]=b[c]);if(o)var i=o(r)}for(a&&a(d);n{"use strict";var e,a,d,c,f,t={},b={};function r(e){var a=b[e];if(void 0!==a)return a.exports;var d=b[e]={id:e,loaded:!1,exports:{}};return t[e].call(d.exports,d,d.exports,r),d.loaded=!0,d.exports}r.m=t,r.c=b,e=[],r.O=(a,d,c,f)=>{if(!d){var t=1/0;for(i=0;i=f)&&Object.keys(r.O).every((e=>r.O[e](d[o])))?d.splice(o--,1):(b=!1,f0&&e[i-1][2]>f;i--)e[i]=e[i-1];e[i]=[d,c,f]},r.n=e=>{var a=e&&e.__esModule?()=>e.default:()=>e;return r.d(a,{a:a}),a},d=Object.getPrototypeOf?e=>Object.getPrototypeOf(e):e=>e.__proto__,r.t=function(e,c){if(1&c&&(e=this(e)),8&c)return e;if("object"==typeof e&&e){if(4&c&&e.__esModule)return e;if(16&c&&"function"==typeof e.then)return e}var f=Object.create(null);r.r(f);var t={};a=a||[null,d({}),d([]),d(d)];for(var b=2&c&&e;"object"==typeof b&&!~a.indexOf(b);b=d(b))Object.getOwnPropertyNames(b).forEach((a=>t[a]=()=>e[a]));return t.default=()=>e,r.d(f,t),f},r.d=(e,a)=>{for(var d in a)r.o(a,d)&&!r.o(e,d)&&Object.defineProperty(e,d,{enumerable:!0,get:a[d]})},r.f={},r.e=e=>Promise.all(Object.keys(r.f).reduce(((a,d)=>(r.f[d](e,a),a)),[])),r.u=e=>"assets/js/"+({53:"935f2afb",533:"b2b675dd",684:"af94d498",695:"0b5ee478",702:"e72a3ded",734:"f349a764",949:"eb83943b",1218:"2dc45ced",1477:"b2f554cd",1713:"a7023ddc",1953:"3e65d5b4",2535:"814f3328",2597:"373392d9",2642:"a81f2d1d",2731:"473435fa",3089:"a6aa9e1f",3106:"581d6198",3345:"ca95d5ad",3608:"9e4087bc",3627:"7c10977a",3824:"9d050fe4",3827:"37fc9d46",3988:"cfd71120",4013:"01a85c17",4128:"a09c2993",4195:"c4f5d8e4",4224:"5c4c46e6",4282:"31d6d5ed",4338:"41206b0e",4468:"1a20bc57",4648:"d558f29a",4904:"b0b0b448",5307:"af32bd62",5310:"476d6aec",5622:"f228e963",5628:"8293a772",5917:"21418ead",5925:"b8b1253e",5943:"a5dc57e5",6103:"ccc49370",6166:"2dfecbce",6412:"b16bf7d2",6439:"2651e53d",6587:"5e677a75",6910:"27315305",6982:"90f022e0",7023:"31fe93dc",7187:"246b6efd",7586:"d22a0e6a",7698:"abda9da4",7918:"17896441",8325:"33b5e0ca",8490:"6b032a97",8528:"5baf5c08",8610:"6875c492",9357:"391ef999",9403:"cc8d6d7f",9407:"ea32bb6f",9428:"283d7b21",9514:"1be78505",9519:"432e378d",9607:"c83e76ae",9675:"14a2b9f8",9704:"60691868"}[e]||e)+"."+{53:"9119e8a8",533:"37b72b08",684:"e1bf73db",695:"9489cc6b",702:"39d9265d",734:"9a7ac39c",949:"31f84837",1218:"b7bd7c4e",1477:"942e1482",1713:"9e1bdfb8",1953:"48c54bb8",2535:"714d8b90",2597:"29477b3f",2642:"253b6a55",2731:"e9977d9e",3089:"2f29c6cf",3106:"c5e44c63",3345:"fffa9184",3608:"62af1a24",3627:"cb3a5eb2",3824:"382fbf8f",3827:"2c5cec8d",3988:"29a57898",4013:"fc514125",4128:"c3a045a0",4195:"c2e74945",4224:"7eabc49e",4282:"52a7d976",4338:"ced36b31",4468:"07c5b6e2",4648:"624c5a42",4904:"e681fb9f",4972:"c98eee24",5307:"55a39fc6",5310:"efb5df1c",5622:"fa7e970f",5628:"df9f83db",5917:"dcdf8c9d",5925:"3745c099",5943:"cd2b7b08",6103:"ae691c92",6166:"1c4e87bb",6412:"0087e5e1",6439:"6af9bd8e",6587:"081a0151",6910:"edee02ea",6921:"f20e80a2",6982:"16ee69ab",7023:"d080ed08",7187:"013bd076",7586:"e17700ba",7698:"009f7f7a",7918:"cbaf46f4",8325:"a6308c17",8490:"7ec6431f",8528:"6656e233",8610:"6363f22a",9357:"8149209a",9403:"60d7af99",9407:"c7edbf91",9428:"894dddce",9514:"c14ec086",9519:"8e24ccc5",9607:"a7dff9eb",9675:"a113c165",9704:"985278fb"}[e]+".js",r.miniCssF=e=>{},r.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),r.o=(e,a)=>Object.prototype.hasOwnProperty.call(e,a),c={},f="website:",r.l=(e,a,d,t)=>{if(c[e])c[e].push(a);else{var b,o;if(void 0!==d)for(var n=document.getElementsByTagName("script"),i=0;i{b.onerror=b.onload=null,clearTimeout(s);var f=c[e];if(delete c[e],b.parentNode&&b.parentNode.removeChild(b),f&&f.forEach((e=>e(d))),a)return a(d)},s=setTimeout(u.bind(null,void 0,{type:"timeout",target:b}),12e4);b.onerror=u.bind(null,b.onerror),b.onload=u.bind(null,b.onload),o&&document.head.appendChild(b)}},r.r=e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},r.nmd=e=>(e.paths=[],e.children||(e.children=[]),e),r.p="/",r.gca=function(e){return e={17896441:"7918",27315305:"6910",60691868:"9704","935f2afb":"53",b2b675dd:"533",af94d498:"684","0b5ee478":"695",e72a3ded:"702",f349a764:"734",eb83943b:"949","2dc45ced":"1218",b2f554cd:"1477",a7023ddc:"1713","3e65d5b4":"1953","814f3328":"2535","373392d9":"2597",a81f2d1d:"2642","473435fa":"2731",a6aa9e1f:"3089","581d6198":"3106",ca95d5ad:"3345","9e4087bc":"3608","7c10977a":"3627","9d050fe4":"3824","37fc9d46":"3827",cfd71120:"3988","01a85c17":"4013",a09c2993:"4128",c4f5d8e4:"4195","5c4c46e6":"4224","31d6d5ed":"4282","41206b0e":"4338","1a20bc57":"4468",d558f29a:"4648",b0b0b448:"4904",af32bd62:"5307","476d6aec":"5310",f228e963:"5622","8293a772":"5628","21418ead":"5917",b8b1253e:"5925",a5dc57e5:"5943",ccc49370:"6103","2dfecbce":"6166",b16bf7d2:"6412","2651e53d":"6439","5e677a75":"6587","90f022e0":"6982","31fe93dc":"7023","246b6efd":"7187",d22a0e6a:"7586",abda9da4:"7698","33b5e0ca":"8325","6b032a97":"8490","5baf5c08":"8528","6875c492":"8610","391ef999":"9357",cc8d6d7f:"9403",ea32bb6f:"9407","283d7b21":"9428","1be78505":"9514","432e378d":"9519",c83e76ae:"9607","14a2b9f8":"9675"}[e]||e,r.p+r.u(e)},(()=>{var e={1303:0,532:0};r.f.j=(a,d)=>{var c=r.o(e,a)?e[a]:void 0;if(0!==c)if(c)d.push(c[2]);else if(/^(1303|532)$/.test(a))e[a]=0;else{var f=new Promise(((d,f)=>c=e[a]=[d,f]));d.push(c[2]=f);var t=r.p+r.u(a),b=new Error;r.l(t,(d=>{if(r.o(e,a)&&(0!==(c=e[a])&&(e[a]=void 0),c)){var f=d&&("load"===d.type?"missing":d.type),t=d&&d.target&&d.target.src;b.message="Loading chunk "+a+" failed.\n("+f+": "+t+")",b.name="ChunkLoadError",b.type=f,b.request=t,c[1](b)}}),"chunk-"+a,a)}},r.O.j=a=>0===e[a];var a=(a,d)=>{var c,f,t=d[0],b=d[1],o=d[2],n=0;if(t.some((a=>0!==e[a]))){for(c in b)r.o(b,c)&&(r.m[c]=b[c]);if(o)var i=o(r)}for(a&&a(d);n Archive | Glean - +

Archive

Archive

2022

- + \ No newline at end of file diff --git a/blog/incremental/index.html b/blog/incremental/index.html index 791f8fd35..5a67fb26b 100644 --- a/blog/incremental/index.html +++ b/blog/incremental/index.html @@ -5,7 +5,7 @@ Incremental indexing with Glean | Glean - + @@ -89,7 +89,7 @@ ownership of x is {A} and y is {B,C} (because it is referred to from z which has owner B), so the final owner of d is {A} && {B,C}.

Tracking all this shouldn't be too expensive, but it's tricky to get right!

- + \ No newline at end of file diff --git a/blog/index.html b/blog/index.html index aac788140..7328eec65 100644 --- a/blog/index.html +++ b/blog/index.html @@ -5,7 +5,7 @@ Blog | Glean - + @@ -89,7 +89,7 @@ ownership of x is {A} and y is {B,C} (because it is referred to from z which has owner B), so the final owner of d is {A} && {B,C}.

Tracking all this shouldn't be too expensive, but it's tricky to get right!

- + \ No newline at end of file diff --git a/blog/tags/glean/index.html b/blog/tags/glean/index.html index f9c073f52..a42776748 100644 --- a/blog/tags/glean/index.html +++ b/blog/tags/glean/index.html @@ -5,7 +5,7 @@ One post tagged with "glean" | Glean - + @@ -89,7 +89,7 @@ ownership of x is {A} and y is {B,C} (because it is referred to from z which has owner B), so the final owner of d is {A} && {B,C}.

Tracking all this shouldn't be too expensive, but it's tricky to get right!

- + \ No newline at end of file diff --git a/blog/tags/incremental/index.html b/blog/tags/incremental/index.html index db70ca725..7d0864d45 100644 --- a/blog/tags/incremental/index.html +++ b/blog/tags/incremental/index.html @@ -5,7 +5,7 @@ One post tagged with "incremental" | Glean - + @@ -89,7 +89,7 @@ ownership of x is {A} and y is {B,C} (because it is referred to from z which has owner B), so the final owner of d is {A} && {B,C}.

Tracking all this shouldn't be too expensive, but it's tricky to get right!

- + \ No newline at end of file diff --git a/blog/tags/index.html b/blog/tags/index.html index a86190a9f..e429a6e8d 100644 --- a/blog/tags/index.html +++ b/blog/tags/index.html @@ -5,14 +5,14 @@ Tags | Glean - +

Tags

- + \ No newline at end of file diff --git a/docs/angle/advanced/index.html b/docs/angle/advanced/index.html index dc7d3067d..f60851e9b 100644 --- a/docs/angle/advanced/index.html +++ b/docs/angle/advanced/index.html @@ -5,14 +5,14 @@ Advanced Query Features | Glean - +

Advanced Query Features

Types and signatures​

Angle queries are strongly typed: the server will check your query for type-safety before executing it. Type-checking ensures that the query makes sense; that it's not trying to pattern-match strings against integers, or look for a field in a record that doesn't exist for example.

Angle's type-checker isn't very clever, though. It mostly doesn't do type inference, it checks that expressions have the intended type. When it doesn't know the intended type of an expression, it uses a dumb inference mode that can only infer the type when it's really obvious: like a fact match, or a string.

facts> P where C = { name = "Fish" }; example.Parent { C, P }
can't infer the type of: {name = "Fish"}
    try adding a type annotation like ({name = "Fish"} : T)
    or reverse the statement (Q = P instead of P = Q)

In cases like this, Angle's type-checker needs a bit of help. We can use a type signature to supply more information about the type:

facts> P where C = { name = "Fish" } : example.Class; example.Parent { C, P }
{ "id": 1024, "key": { "name": "Pet", "line": 10 } }

Here we used { name = "Fish" } : example.Class to tell Angle the expected type of the pattern. You should read the colon as "has type", and the type can be any valid Angle type, for details see Built-in types.

Explicit fact IDs​

Every fact has an ID, which is a 64-bit integer that uniquely identifies the fact in a particular database. You've probably noticed these fact IDs in the query results: every result has an id field with the fact ID, and a key field with the fact key.

Most Angle queries don't need to mention fact IDs explicitly, but sometimes it's useful. For example, you might need to perform a query to fetch some results, do some custom filtering on the results and then query Glean again using some of the fact IDs from the first query.

WARNING: a fact ID only makes sense in the context of a particular database, so make sure that your query that mentions fact IDs is being made on the same database that you obtained the fact ID from originally.

Glean has a syntax for referring to fact IDs directly; for example

facts> $1026 : example.Class
{ "id": 1026, "key": { "name": "Fish", "line": 30 } }

the syntax is $<fact ID>, but you will often want to use it with a type signature, as $<fact ID> : <predicate>.

If you get the predicate wrong, Glean will complain:

facts> $1026 : example.Parent
*** Exception: fact has the wrong type

The type can be omitted only if it is clear from the context, for example

facts> example.Parent { child = $1026 }
{ "id": 1029, "key": { "child": { "id": 1026 }, "parent": { "id": 1024 } } }

Sometimes you might want to use multiple fact IDs in a query. Or-patterns come in handy here:

facts> example.Parent { child = $1026 | $1027 }

Functional predicates​

All the predicates we've seen so far have been key-only predicates. A predicate can also have a value; we call these functional predicates or key-value predicates.

For example, we might model a reference to a class in our example schema like this:

predicate Reference :
  { file : string, line : nat, column : nat } -> Class

This says that for a given (file,line,column) there can be at most one reference to a Class. This uniqueness is the important property of a key-value predicate: for each key there is at most one value.

We query for key-value predicates using this syntax:

facts> C where example.Reference { file = "x", line = 1, column = 2 } -> C

The pattern after the -> matches the value. It can be an arbitrary pattern, just like the key. Note that facts cannot be efficiently searched by value, so the pattern that matches the value is a filter only.

- + \ No newline at end of file diff --git a/docs/angle/debugging/index.html b/docs/angle/debugging/index.html index f8d997d01..8f300a1ec 100644 --- a/docs/angle/debugging/index.html +++ b/docs/angle/debugging/index.html @@ -5,7 +5,7 @@ Debugging | Glean - + @@ -15,7 +15,7 @@ shell, where you can experiment with queries quickly and easily.

If you're writing particularly complex queries, then consider using Derived Predicates to structure your query and to allow parts of the query to be re-used. To iterate on derived predicates, see How do I write and test a derived predicate?

Debugging a slow query​

Performance debugging can be tricky, because Angle is a very declarative language. There are often many ways to write the query that are correct, but not all of them will be fast.

The shell provides a few facilities to help with this.

> :profile full

Turning on query profiling allows you to see how many facts of each predicate are being searched by your query. For example:

fbsource> search.cxx.SearchByNameAndScope { name = "Future" }
...
Facts searched:
                cxx1.RecordDeclaration.1 : 103
             cxx1.TypeAliasDeclaration.2 : 11
                            cxx1.QName.1 : 8
              cxx1.VariableDeclaration.2 : 7
                  cxx1.EnumDeclaration.1 : 7
                             cxx1.Name.1 : 1

If your query is expensive, then likely you will see some large numbers next to one or more predicates. This is a sign that you probably want to reorder the statements in your query, or lift out some nested queries into statements so that you can control the ordering more precisely.

> :debug on

Showing the internals​

The shell provides ways to show what Glean's query engine is doing internally. This is mostly useful for those working on the query engine itself, but it might also be helpful when debugging queries.

danger

We provide no guarantees about this functionality and it might change without warning.

> :debug ir

Shows the internal representation of the query after parsing, name resolution, type checking, and various transformations to simplify it. In particular, all the nesting has been flattened at this stage, so you can see the exact order of the searches on each predicate, which might help with performance debugging.

> :debug bytecode

Shows the compiled bytecode for the query. This is what Glean's virtual machine (VM) will execute to perform the query. Probably not all that useful for debugging queries.

- + \ No newline at end of file diff --git a/docs/angle/efficiency/index.html b/docs/angle/efficiency/index.html index 6c6a1ae3d..612825edd 100644 --- a/docs/angle/efficiency/index.html +++ b/docs/angle/efficiency/index.html @@ -5,14 +5,14 @@ Query Efficiency | Glean - +

Query Efficiency

There are two important aspects of a query that affect its efficiency;

  1. Which fields are specified in a pattern
  2. The ordering of statements

We’ll cover each of these in the following sections.

Efficient matching of facts​

The order of fields in the schema matters a lot for efficiency. Glean indexes facts by a prefix of their keys, so if we know the prefix when searching for facts this will be a lot faster. Often this difference is absolutely crucial; the difference is between O(log n) and O(n), so when the database is large this can be many orders of magnitude.

For example, the example.Parent predicate we saw earlier is defined as

predicate Parent :
  {
    child : Person,
    parent : Person,
  }

We should think of this as a mapping from child to parent. Glean won’t stop you writing a query for { parent = ... }, but such a query will examine all of the example.Parent facts in the database. We can see how many facts are searched for our query using :profile full in the shell (see debugging for more details):

facts> :profile full
facts> example.Parent { parent = { name = "Pet" }}
(snip)
2 results, 2 facts, 0.40ms, 159440 bytes, 988 compiled bytes
Facts searched:
                        example.Parent.1 : 3

This tells us that although it found the 2 results we expected, it searched all 3 example.Parent facts in the process.

Making queries efficient using a derived predicate​

What if we wanted to efficiently map from parent to child? That’s easy to accomplish using a derived predicate. We’re going to define a new predicate with a different field ordering, and automatically generate the facts of our new predicate by deriving them from the facts of the existing predicate. For full details see Derived Predicates, what follows will be a walkthrough showing how to use a derived predicate to make our queries more efficient.

First we’ll define our derived predicate in the schema, like this:

predicate Child :
  {
    parent : Class,
    child : Class,
  }
  stored
  { P, C } where Parent { C, P }

We can try this out in the shell. First we have to create a new database to hold the derived facts that is stacked on top of the old database. Drop out of the shell and run this command to create the new database:

glean create --db-root /tmp/glean/db --schema dir:/tmp/glean/schema --db derived/1 --stacked facts/1

Now start the shell again and load the stacked database. Note that we can still query facts from the original database:

> :db derived/1
derived> example.Parent _
{ "id": 1028, "key": { "child": { "id": 1025 }, "parent": { "id": 1024 } } }
{ "id": 1029, "key": { "child": { "id": 1026 }, "parent": { "id": 1024 } } }
{ "id": 1030, "key": { "child": { "id": 1027 }, "parent": { "id": 1026 } } }

Initially we have no facts of the Child predicate:

derived> example.Child _
0 results, 0 facts, 0.91ms, 812952 bytes, 664 compiled bytes

But we can create them automatically:

(TODO: check this still works, do we need a :derive command now?)

derived> * example.Child _
{ "id": 1037, "key": { "parent": { "id": 1024 }, "child": { "id": 1025 } } }
{ "id": 1038, "key": { "parent": { "id": 1024 }, "child": { "id": 1026 } } }
{ "id": 1039, "key": { "parent": { "id": 1026 }, "child": { "id": 1027 } } }

(the * means “derive and store” the facts produced by the query. To derive facts for a production database you would use either glean derive from the command line, or the appropriate Thrift API in whatever language you’re using to talk to the Glean server).

Now we have 3 facts of our derived predicate:

derived> :stat
example.Child.1
  count: 3
  size:  87 (87 bytes) 100.0000%

And finally we can make efficient queries to find a parent’s children:

derived> example.Child { parent = { name = "Pet" }}
{ "id": 1037, "key": { "parent": { "id": 1024 }, "child": { "id": 1025 } } }
{ "id": 1038, "key": { "parent": { "id": 1024 }, "child": { "id": 1026 } } }

2 results, 2 facts, 0.41ms, 160992 bytes, 1013 compiled bytes
Facts searched:
                         example.Child.1 : 2
                         example.Class.1 : 1

We found the correct 2 results, and only searched 2 example.Child facts.

This idea of adding extra indices to your database using derived predicates is common practice when working with Glean data, so it’s worthwhile getting familiar with it.

The order of statements is important​

Suppose we want to find the grandparent of the Goldfish class using our example schema. We would probably write it like this:

Q where
    example.Parent { child = { name = "Goldfish" }, parent = P };
    example.Parent { child = P, parent = Q }

Generally speaking the statements are matched top-to-bottom. For each of the facts that match the first statement, bind the variables in the pattern and then proceed with the second statement, and so on.

As written, this query works by first finding the parent of Goldfish and then finding its parent, which is exactly what we want. This query will be efficient, because both stages are matching on the first field of the example.Parent predicate.

If instead we swapped the order of the statements:

Q where
    example.Parent { child = P, parent = Q };
    example.Parent { child = { name = "Goldfish" }, parent = P }

The query still works, and means exactly the same thing, but it’s much less efficient. This query works as follows:

  • for each example.Parent fact, call the child P and the parent Q
  • search for an example.Parent fact with child { name = "Goldfish" } and parent P
  • if it exists, then Q is a result

This is going to involve searching all of the example.Parent facts, instead of just the ones for the parent of Goldfish.

The general rule of thumb is to do the more specific searches first. The search for example.Parent { child = { name = "Goldfish" }, parent = P } is efficient because we know the child, this binds he value of P which makes the search for example.Parent { child = P, parent = Q } also fast.

- + \ No newline at end of file diff --git a/docs/angle/guide/index.html b/docs/angle/guide/index.html index b7bf320ee..812a9546f 100644 --- a/docs/angle/guide/index.html +++ b/docs/angle/guide/index.html @@ -5,7 +5,7 @@ Angle Guide | Glean - + @@ -31,11 +31,11 @@ better, to do this in the shell you will need to use the :edit command to put the query in a temporary file.

The key thing here is that we used a variable C to stand for the class_ field when matching facts of example.Has, and then we searched for example.Parent facts with the same value of C for the child field.

Note that variables must always begin with an upper-case letter, while schema names (example) and field names (child) begin with a lower-case letter.

The semicolon separates multiple statements in a query. When there are multiple statements the results of the query are the facts that match the last statement, in this case the example.Parent. Let’s try it:

facts> example.Has { class_ = C, has = { variable = { name = "fins" }}}; example.Parent { child = C }
{
  "id": 1029,
  "key": {
    "child": { "id": 1026, "key": { "name": "Fish", "line": 30 } },
    "parent": { "id": 1024, "key": { "name": "Pet", "line": 10 } }
  }
}

Suppose we don’t care too much about the child here, we only care about getting a list of the parents. We can avoid returning the redundant information by specifying explicitly what it is we want to return from the query:

P where
    example.Has
      {
        class_ = C,
        has = { variable = { name = "fins" }}
      };
    example.Parent { child = C, parent = P }

The general form of the query is expression where statements, where expression is an arbitrary expression and each statement is a pattern that matches some facts. The results of the query are the distinct values of expression for which all the statements match facts in the database.

facts> P where example.Has { class_ = C, has = { variable = { name = "fins" }}}; example.Parent { child = C, parent = P }
{ "id": 1024, "key": { "name": "Pet", "line": 10 } }

Statements​

In general, a statement can be of the form A = B. For example, if we write

C = example.Class { name = "Fish" };
example.Parent { child = C }

that’s the same as

example.Parent { child = { name = "Fish" }}

A statement can have a pattern on either side, for example

C where
  C = example.Class { name = N };
  N = "Fish" | "Goldfish"

A statement can itself be a set of alternatives separated by a vertical bar |. For example, we can find classes that are either a parent of the Goldfish or have a feed method:

C where
  example.Parent { child = { name = "Goldfish" }, parent = C } |
  example.Has { class_ = C, has = { method = { name = "feed" }}}

Arrays​

When the schema uses an array, we need to be able to write queries that traverse the elements of the array. For example, a common use of an array is to represent the list of declarations in a source file. Our example schema defines the FileClasses predicate:

predicate FileClasses :
  {
    file : string,
    classes : [Class]
  }

The goal here is to map efficiently from a filename to the list of classes defined in that file. Suppose we want to write a query that finds all the classes called Goldfish in the file petshop.example, we could do it like this:

example.FileClasses { file = "petshop.example", classes = Cs };
{ name = "Goldfish" } = Cs[..]

The second line is the interesting one: { name = "Goldfish" } = Cs[..] means

  • on the right-hand side, Cs[..] means “each element of the array Cs”
  • the left-hand side is a pattern, filtering only those Class facts that match { name = "Goldfish" }

We can also match the whole array with a pattern of the form [ p1, p2, .. ]

facts> X where [_,X,_] = [1,2,3]
{ "id": 1040, "key": 2 }

Or if we don't care about the length of the array:

facts> X where [_,X, ..] = [1,2,3]
{ "id": 1040, "key": 2 }

String prefix​

We’ve seen many examples of patterns that match strings. Glean also supports matching strings by prefix; for example:

facts> example.Class { name = "F".. }
{ "id": 1026, "key": { "name": "Fish", "line": 30 } }

The syntax "F".. means strings beginning with the prefix ”F".

note

Why only prefix and not substring matching in general? Prefix matching can be supported efficiently by Glean’s prefix-tree representation of the fact database. Other kinds of string matching could be supported, but they wouldn’t be able to exploit the database representation so there’s little advantage to implementing them in Angle compared with filtering on the client-side.

Tuples​

A tuple is just a a way of writing a record without the field names. So for example, instead of

example.Parent { child = C }

we could write

example.Parent { C, _ }

When using a tuple you have to list all the fields, in the same order as they are declared in the schema. That's why { child = C } becomes { C, _ } when written as a tuple.

There are upsides and downsides to using the tuple notation:

  • Pro: more concise
  • Con: brittle and sensitive to changes in the schema. If we add a field, then tuple patterns will break whereas record patterns won't.

As a rule of thumb we tend to use tuple syntax in cases where the predicate is "obviously" a relation, such as example.Parent, but we wouldn't use tuple syntax for more complex records.

Enums and bool​

An enum type is a set of named constants. In the Has predicate we used an enum type to indicate whether a class member is Public or Private:

predicate Has :
  {
    class_ : Class,
    has : Member,
    access : enum { Public | Private },
  }

To match an enum we just use the appropriate identifier, in this case Public or Private:

facts> example.Has { access = Private }
{ "id": 1036, "key": { "class_": { "id": 1026 }, "has": { "id": 1035 }, "access": 1 } }

Note that in the JSON format results, an enum is represented by an integer. When you make queries in code, the enum will be represented by an appropriate type, such as a data type in Haskell.

The boolean type bool is a special case of an enum, defined like this:

type bool = enum { false | true }

Negation​

If we want results that do not match a certain criterion, we can use ! to specify a subquery that should fail. A subquery fails if it doesn't return any -result.

For example, we can find classes that don't have methods

facts> C where C = example.Class _; !(example.Has { class_ = C, has = { method = _ } })
{ "id": 1026, "key": { "name": "Fish", "line": 30 } }
{ "id": 1027, "key": { "name": "Goldfish", "line": 40 } }
{ "id": 1025, "key": { "name": "Lizard", "line": 20 } }

Or we could find the maximum element in an array

facts> X where Values = [5,1,2,3]; X = Values[..]; !(Y = Values[..]; Y > X);
{ "id": 1091, "key": 5 }

The query asks for the X for which given all values of Y none is greater +result.

For example, we can find classes that don't have methods

facts> C where C = example.Class _; !(example.Has { class_ = C, has = { method = _ } })
{ "id": 1026, "key": { "name": "Fish", "line": 30 } }
{ "id": 1027, "key": { "name": "Goldfish", "line": 40 } }
{ "id": 1025, "key": { "name": "Lizard", "line": 20 } }

Or we could find the maximum element in an array

facts> X where Values = [5,1,2,3]; X = Values[..]; !(Y = Values[..]; Y > X)
{ "id": 1091, "key": 5 }

The query asks for the X for which given all values of Y none is greater than it. If Y = Values[..] were outside of the negation, the meaning would be give me all X for which there is at least one Y that is not greater than it. The answer to that would be all elements.

- + \ No newline at end of file diff --git a/docs/angle/intro/index.html b/docs/angle/intro/index.html index ddb56062c..cff999034 100644 --- a/docs/angle/intro/index.html +++ b/docs/angle/intro/index.html @@ -5,7 +5,7 @@ Angle Introduction | Glean - + @@ -16,7 +16,7 @@ particularly suited for finding and extracting data from Glean.

To give you a flavour of the query language, here is how we could return the names of all the member declarations defined in a JavaScript file project/myfile.js:

N where
  flow.FileDeclaration {
    file = "project/myfile.js",
    declaration = {
      memberDecl = {
        name = N
      }
    }
  }

To learn about Angle, start with the Guide.

- + \ No newline at end of file diff --git a/docs/angle/reference/index.html b/docs/angle/reference/index.html index bb2616d8e..bd68f1619 100644 --- a/docs/angle/reference/index.html +++ b/docs/angle/reference/index.html @@ -5,7 +5,7 @@ Angle Reference | Glean - + @@ -24,7 +24,7 @@   term < term
  term <= term
  term !== term

Standard numerical comparisons. These work on values of type nat only, and they have value {} if the comparison succeeds, otherwise they fail (in the same way as a predicate match fails if there are no facts that match the pattern).

  term != term

Standard comparison between two terms of any type. It has a value of {} if the comparison succeeds, otherwise it fails in the same way as a predicate match fails if there are no facts that match the pattern.

- + \ No newline at end of file diff --git a/docs/angle/style/index.html b/docs/angle/style/index.html index 66e998315..b97727ec8 100644 --- a/docs/angle/style/index.html +++ b/docs/angle/style/index.html @@ -5,14 +5,14 @@ Angle Style Guide | Glean - +

Angle Style Guide

Typical Angle style uses the following rules:

  • 2-column indentation
  • trailing commas
  • open/close braces on a line by themselves
  • camel case for record field names

e.g.

# Named parameter
type Parameter =
  {
    name : Name,
    type : Type,
    isVariadic : bool,
  }

This uses quite a lot of vertical space, but it's clear and works well with source control.

It's OK to put things on a single line if they fit:

type Access = enum { Public | Protected | Private }
- + \ No newline at end of file diff --git a/docs/building/index.html b/docs/building/index.html index a0c61b61f..ea44435b6 100644 --- a/docs/building/index.html +++ b/docs/building/index.html @@ -5,7 +5,7 @@ Building Glean from Source | Glean - + @@ -26,7 +26,7 @@ build and install its dependencies:

./install_deps.sh

Build Glean​

Now you can build all the Glean parts:

make

If everything worked, the tests should pass:

make test

At this point you can cabal install to install the executables into ~/.cabal/bin.

Tips for faster builds​

If you have 4 or more cores and at least 16G of ram, you can significantly speed up the build times by passing some flags to the build stages. On an 6 core machine with 16G of ram you might use, to save 50% or more of the build time.

./install_deps.sh --threads 6
make EXTRA_GHC_OPTS='-j4 +RTS -A128m -n2m -RTS'

Using clang++-12 and clang-12 as the C and C++ compilers can shave another 25% off the build time.

- + \ No newline at end of file diff --git a/docs/cli/index.html b/docs/cli/index.html index 8fb75aca5..c4fb8556d 100644 --- a/docs/cli/index.html +++ b/docs/cli/index.html @@ -5,7 +5,7 @@ The Glean CLI tool | Glean - + @@ -71,7 +71,7 @@ once a database is marked complete it could be replicated, so we shouldn't be modifying it.

  • --db NAME/INSTANCE or --db-name NAME --db-instance INSTANCE
    Specifies the name and instance of the database
- + \ No newline at end of file diff --git a/docs/databases/index.html b/docs/databases/index.html index b78ab09f5..824cd4940 100644 --- a/docs/databases/index.html +++ b/docs/databases/index.html @@ -5,7 +5,7 @@ Glean Databases | Glean - + @@ -20,7 +20,7 @@ index the current state of a source repository. The process works like this:

  • The job invokes glean create --service <write-server> <args> to create the database.

  • At this point the database is in the Incomplete state. Queries are supported in this state, and always reflect the current contents.

  • Facts are written to the database using the methods described in Writing data to Glean, and finally the database is closed by invoking glean finish --service <write-server> <args> or the appropriate Thrift method.

  • The database is now in the Complete state.

  • If backups are allowed for this database, then:

    • the write server uploads the database to backup storage.
    • servers that are configured to restore databases automatically can download the DB from backup storage, and use it to serve queries from clients.
note

There are currently no backup backends implemented for open-source Glean.

- + \ No newline at end of file diff --git a/docs/derived/index.html b/docs/derived/index.html index 49619a6a2..b360d1e8f 100644 --- a/docs/derived/index.html +++ b/docs/derived/index.html @@ -5,7 +5,7 @@ Derived Predicates | Glean - + @@ -39,7 +39,7 @@ describes the data in the rest of the stack.

If you need to test changes to an existing predicate, copy the predicate and give it a new name to test it, and then fold the changes back into the original when you've finished testing.

Now, you can derive your new predicate:

glean derive --db-root ~/local/gleandb --db stacked/0 my.new.Predicate

and inspect the results in the shell:

glean shell --db-root ~/local/gleandb --db stacked/0
- + \ No newline at end of file diff --git a/docs/implementation/incrementality/index.html b/docs/implementation/incrementality/index.html index 7910e836b..854b8b60a 100644 --- a/docs/implementation/incrementality/index.html +++ b/docs/implementation/incrementality/index.html @@ -5,7 +5,7 @@ Incrementality | Glean - + @@ -97,7 +97,7 @@ ownership of the derived facts. Incremental derivation must therefore consider facts that have new ownership in the stacked DB when deriving. At the time of writing, this isn't implemented yet.

- + \ No newline at end of file diff --git a/docs/indexer/cxx/index.html b/docs/indexer/cxx/index.html index fc36a6ad4..d2485303e 100644 --- a/docs/indexer/cxx/index.html +++ b/docs/indexer/cxx/index.html @@ -5,7 +5,7 @@ C++ and C | Glean - + @@ -28,7 +28,7 @@ PATH variable for this to succeed, or in the build tree.

Schema​

The schema is in glean/schema/source/cxx.angle

The schema is quite rich and captures C++, C, Objective-C and C pre-processor symbols, the semantic structure of C++ symbols, and is precise enough to do automated analysis of C++ code.

- + \ No newline at end of file diff --git a/docs/indexer/flow/index.html b/docs/indexer/flow/index.html index 8ad4e5a69..54eaabd5b 100644 --- a/docs/indexer/flow/index.html +++ b/docs/indexer/flow/index.html @@ -5,7 +5,7 @@ JavaScript (Flow) | Glean - + @@ -16,7 +16,7 @@ in the Glean demo Docker image to try out.

Run the indexer​

The indexer is run via the main glean CLI tool.

> cabal build exe:glean

And index your Flow repository with:

glean index flow DIR --db NAME/INSTANCE

where

  • DIR is the root directory containing the Flow project (with .flowconfig)
  • name/hash is the name of the repository to create

Provide the usual --db-root and --schema or --service arguments to glean

Run the indexer (manually)​

flow glean DIR --output-dir JSON --write-root PREFIX

where

  • DIR is the root directory containing the JavaScript/Flow files
  • JSON is the directory in which to write the output .json files
  • PREFIX is a prefix to add to the files in the Glean index (this can be empty if you don't need a prefix)

The generated files can be ingested into a Glean database using glean create.

Derived predicates​

Several predicates should be derived after indexing. For each stored predicate in the schema you should glean derive the predicate.

In the shell​

Flow source can also be indexed directly from the Glean shell:

:index flow DIR

Schema​

The schema is in glean/schema/source/flow.angle

- + \ No newline at end of file diff --git a/docs/indexer/hack/index.html b/docs/indexer/hack/index.html index 011bf58ec..84fc552ff 100644 --- a/docs/indexer/hack/index.html +++ b/docs/indexer/hack/index.html @@ -5,7 +5,7 @@ Hack | Glean - + @@ -13,7 +13,7 @@

Hack

The Hack indexer is built into the Hack typechecker. Stable and nightly binaries of the Hack indexer are available.

Run the indexer​

The indexer is run via the main glean CLI tool.

> cabal build exe:glean

And index your Hack repository with:

glean index hack DIR --db NAME/INSTANCE

where

  • DIR is the root directory containing the Hack project (with .hhconfig)
  • name/hash is the name of the repository to create

Provide the usual --db-root and --schema or --service arguments to glean

In the shell​

Hack source can also be indexed directly from the Glean shell:

:index hack DIR

Run the indexer (manually)​

hh_server DIR --write-symbol-info JSON \
  --config symbol_write_include_hhi=false \
  --config symbolindex_search_provider=NoIndex \
  --config lazy_decl=true \
  --config lazy_parse=true \
  --config lazy_init2=true \

where

  • DIR is the root directory containing the .php files
  • JSON is the directory in which to write the output .json files
  • We need several config flags to instantiate hh_server for indexing

The generated files can be ingested into a Glean database using glean create.

Derived predicates​

Several predicates should be derived after indexing. For each stored predicate in the schema you should glean derive the predicate.

Schema​

The schema is in glean/schema/source/hack.angle

- + \ No newline at end of file diff --git a/docs/indexer/haskell/index.html b/docs/indexer/haskell/index.html index ff9b5bb25..087cab663 100644 --- a/docs/indexer/haskell/index.html +++ b/docs/indexer/haskell/index.html @@ -5,14 +5,14 @@ Haskell | Glean - +

Haskell

To index Haskell Glean consumes .hie files produced by the GHC compiler (>=8.8) with the flag -fwrite-ide-info.

Run the indexer

The indexer is run via the main glean CLI tool.

BUILD --ghc-options=-fwrite-ide-info
glean --db-root DBDIR index haskell ROOT --db NAME/INSTANCE

where

  • BUILD is a build command such that GHC is called with -fwrite-ide-info
  • DBDIR is the directory where the Glean db will be created
  • ROOT is the root directory containing the build artifacts generated with the fwrite-ide-info flag (e.g. dist if a Cabal project)
  • name/hash is the name of the repository to create

Schema​

The schema is in

- + \ No newline at end of file diff --git a/docs/indexer/intro/index.html b/docs/indexer/intro/index.html index 4b545f369..9c78a0ebb 100644 --- a/docs/indexer/intro/index.html +++ b/docs/indexer/intro/index.html @@ -5,7 +5,7 @@ Introduction | Glean - + @@ -15,7 +15,7 @@ Glean, and how to use them. Indexers are programs that analyze source code to produce facts for Glean to store. They may be standalone programs, or part of existing IDE or language tools.

- + \ No newline at end of file diff --git a/docs/indexer/lsif-go/index.html b/docs/indexer/lsif-go/index.html index d05a93e4f..f5e65956f 100644 --- a/docs/indexer/lsif-go/index.html +++ b/docs/indexer/lsif-go/index.html @@ -5,7 +5,7 @@ Go | Glean - + @@ -13,7 +13,7 @@

Go

To index Go we use SourceGraph's LSIF indexer for Go. LSIF is a new format for tools to share information about code. Binary releases of lsif-go are available ffor x86 Linux which will work as Glean indexers. The LSIF indexer uses a recent (>1.15) version of Go.

Run the indexer​

The indexer is run via the main glean CLI tool.

> cabal build exe:glean

And index your Go repository with:

glean index go DIR --db NAME/INSTANCE

where

  • DIR is the root directory containing the Go project
  • name/hash is the name of the repository to create

Provide the usual --db-root and --schema or --service arguments to glean

In the shell​

Go source can also be indexed directly from the Glean shell:

:index go DIR

The shell will pick a DB name and hash for you based on DIR.

Schema​

The schema is in glean/schema/source/lsif.angle

- + \ No newline at end of file diff --git a/docs/indexer/lsif-java/index.html b/docs/indexer/lsif-java/index.html index 6ba054b51..c0d4da755 100644 --- a/docs/indexer/lsif-java/index.html +++ b/docs/indexer/lsif-java/index.html @@ -5,7 +5,7 @@ Java | Glean - + @@ -22,7 +22,7 @@ to glean

In the shell​

Java source can also be indexed directly from the Glean shell:

:index java-lsif DIR

The shell will pick a DB name and hash for you based on DIR. You can also run lsif-java offline, and then :load the resulting lsif file into the shell.

Schema​

The schema is in glean/schema/source/lsif.angle

- + \ No newline at end of file diff --git a/docs/indexer/lsif-rust/index.html b/docs/indexer/lsif-rust/index.html index 56c9da266..c985636b1 100644 --- a/docs/indexer/lsif-rust/index.html +++ b/docs/indexer/lsif-rust/index.html @@ -5,7 +5,7 @@ Rust | Glean - + @@ -13,7 +13,7 @@

Rust

To index Rust we use rust-analyzer in LSIF mode. Pre-built binaries of rust-analyzer can be used as indexers that emit LSIF from Rust source.

Run the indexer​

The indexer is run via the main glean CLI tool.

> cabal build exe:glean

And index your Rust repository with:

glean index rust-lsif DIR --db NAME/INSTANCE

where

  • DIR is the root directory containing the Rust project
  • name/hash is the name of the repository to create

Provide the usual --db-root and --schema or --service arguments to glean

In the shell​

Rust source can also be indexed directly from the Glean shell:

:index rust-lsif DIR

The shell will pick a DB name and hash for you based on DIR.

Schema​

The schema is in glean/schema/source/lsif.angle

- + \ No newline at end of file diff --git a/docs/indexer/lsif-typescript/index.html b/docs/indexer/lsif-typescript/index.html index 292cdcbea..f3821423e 100644 --- a/docs/indexer/lsif-typescript/index.html +++ b/docs/indexer/lsif-typescript/index.html @@ -5,7 +5,7 @@ TypeScript | Glean - + @@ -13,7 +13,7 @@

TypeScript

To index TypeScript we use SourceGraph's LSIF indexer for TypeScript. LSIF is a new format for tools to share information about code. Releases of lsif-tsc can be installed with yarn or npm and used as indexers for LSIF, which Glean will accept. The indexer itself requires a node.js runtime.

Run the indexer​

The indexer is run via the main glean CLI tool.

> cabal build exe:glean

And index your TypeScript repository with:

glean index typescript DIR --db NAME/INSTANCE

where

  • DIR is the root directory containing the TypeScript project
  • name/hash is the name of the repository to create

Provide the usual --db-root and --schema or --service arguments to glean

To index very large TypeScript repositories, it may be necessary to use more heap memory in node.js (or break up the targets into subdirectories). Setting export NODE_OPTIONS="--max-old-space-size=8192" in the environment in which the indexer runs may help.

In the shell​

TypeScript source can also be indexed directly from the Glean shell:

:index typescript DIR

The shell will pick a DB name and hash for you based on DIR.

Schema​

The schema is in glean/schema/source/lsif.angle

- + \ No newline at end of file diff --git a/docs/indexer/scip-dotnet/index.html b/docs/indexer/scip-dotnet/index.html index fc2904ad4..319713f14 100644 --- a/docs/indexer/scip-dotnet/index.html +++ b/docs/indexer/scip-dotnet/index.html @@ -5,7 +5,7 @@ Dotnet | Glean - + @@ -13,7 +13,7 @@

Dotnet

To index Dotnet we use SourceGraph's SCIP indexer for dotnet. SCIP is a new format for tools to share information about code. Releases of scip-dotnet can be installed with dotnet tools and used as indexers for SCIP, which Glean will accept. The indexer itself requires a dotnet runtime environment.

Run the indexer​

The indexer is run via the main glean CLI tool.

> cabal build exe:glean

And index your Dotnet repository with:

glean index dotnet-scip DIR --db NAME/INSTANCE

where

  • DIR is the root directory containing the Dotnet project
  • name/hash is the name of the repository to create

Provide the usual --db-root and --schema or --service arguments to glean

In the shell​

Dotnet source can also be indexed directly from the Glean shell:

:index dotnet-scip DIR

The shell will pick a DB name and hash for you based on DIR.

Schema​

The schema is in glean/schema/source/scip.angle

- + \ No newline at end of file diff --git a/docs/indexer/scip-python/index.html b/docs/indexer/scip-python/index.html index 898f8f21d..64602fefb 100644 --- a/docs/indexer/scip-python/index.html +++ b/docs/indexer/scip-python/index.html @@ -5,7 +5,7 @@ Python | Glean - + @@ -13,7 +13,7 @@

Python

To index Python we use SourceGraph's SCIP indexer for python. SCIP is a new format for tools to share information about code. Releases of scip-python can be installed with yarn or npm and used as indexers for SCIP, which Glean will accept. The indexer itself requires a python runtime.

Run the indexer​

The indexer is run via the main glean CLI tool.

> cabal build exe:glean

And index your Python repository with:

glean index python-scip DIR --db NAME/INSTANCE

where

  • DIR is the root directory containing the Python project
  • name/hash is the name of the repository to create

Provide the usual --db-root and --schema or --service arguments to glean

In the shell​

Python source can also be indexed directly from the Glean shell:

:index python-scip DIR

The shell will pick a DB name and hash for you based on DIR.

Schema​

The schema is in glean/schema/source/scip.angle

- + \ No newline at end of file diff --git a/docs/introduction/index.html b/docs/introduction/index.html index 212c4d767..2da8086d8 100644 --- a/docs/introduction/index.html +++ b/docs/introduction/index.html @@ -5,7 +5,7 @@ Introduction | Glean - + @@ -51,7 +51,7 @@ want to support. Usually that means things like the locations of definitions and cross-references, but not expressions.↩
  • If you're familiar with Datalog, it's worth noting that currently Angle is limited to non-recursive queries only.↩
    • - + \ No newline at end of file diff --git a/docs/query/api/haskell/index.html b/docs/query/api/haskell/index.html index aca35ba89..8f97a367d 100644 --- a/docs/query/api/haskell/index.html +++ b/docs/query/api/haskell/index.html @@ -5,7 +5,7 @@ Haskell Query API | Glean - + @@ -23,7 +23,7 @@ request to Glean. This makes it efficient to do shallow queries and then selectively traverse and expand the results as needed.

    To use the API, import Glean.Haxl. The implementation of the API is in glean/haxl/Haxl/DataSource/Glean.hs.

    - + \ No newline at end of file diff --git a/docs/query/haskell/index.html b/docs/query/haskell/index.html index b45dd511a..84352e2fd 100644 --- a/docs/query/haskell/index.html +++ b/docs/query/haskell/index.html @@ -5,14 +5,14 @@ Haskell Query API | Glean - +
    - + \ No newline at end of file diff --git a/docs/query/intro/index.html b/docs/query/intro/index.html index 3efd1e2e2..968c4c54e 100644 --- a/docs/query/intro/index.html +++ b/docs/query/intro/index.html @@ -5,7 +5,7 @@ Querying Glean | Glean - + @@ -27,7 +27,7 @@ that you can install in VS Code by following the instructions in the next section.

    Installing​

    code --install-extension path/to/glean-x.y.z.vsix

    The VS Code documentation describes alternative ways to install an extension from a .vsix file, from within the editor, in case the above command does not work or a more graphical, user-friendly is preferable.

    - + \ No newline at end of file diff --git a/docs/running/index.html b/docs/running/index.html index 5c25de5ff..b601a73af 100644 --- a/docs/running/index.html +++ b/docs/running/index.html @@ -5,7 +5,7 @@ Running the Tools | Glean - + @@ -52,7 +52,7 @@ created, so it is likely to be a correct description of the data in the database.

  • --db-mock-writes
    Allow write operations, but discard the data and don't write it to the DB.

    • - + \ No newline at end of file diff --git a/docs/schema/all/index.html b/docs/schema/all/index.html index f858ce654..dda5c92d5 100644 --- a/docs/schema/all/index.html +++ b/docs/schema/all/index.html @@ -5,7 +5,7 @@ The special "all" schema | Glean - + @@ -26,7 +26,7 @@ all separately, and clients can select at build time which version they want to use. This enables incremental migration of code from one schema to another schema.

    - + \ No newline at end of file diff --git a/docs/schema/basic/index.html b/docs/schema/basic/index.html index 418d97337..fb70d289c 100644 --- a/docs/schema/basic/index.html +++ b/docs/schema/basic/index.html @@ -5,7 +5,7 @@ Basic Concepts | Glean - + @@ -23,7 +23,7 @@ patterns that match multiple keys, and get back all the facts that match the pattern. More about this when we talk about Angle queries.

    - + \ No newline at end of file diff --git a/docs/schema/changing/index.html b/docs/schema/changing/index.html index 2131aca6e..f00dc382d 100644 --- a/docs/schema/changing/index.html +++ b/docs/schema/changing/index.html @@ -5,7 +5,7 @@ How do I change a schema? | Glean - + @@ -52,7 +52,7 @@ which can be useful if you want to perform schema changes in a more explicit way, or to rename schemas.

    The feature is enabled using a top-level directive

    schema my_schema.2 evolves my_schema.1

    This declaration has the effect of treating queries for my_schema.1 predicates as if they were for my_schema.2. That is the query results will be retrieved from the database in the shape of a my_schema.2 fact and transformed into a fact of the equivalent my_schema.1 predicate specified in the query.

    The new schema must contain all the predicates of the old schema, either with new versions or old versions, and their definitions must be backwards compatible. We can achieve this by copying the entire content of the old schema into the new one and modifying it there.

    Now what should Glean do when a client asks for a fact from an old schema?

    • Answer with db facts from the old schema
    • Answer with db facts from the new schema transformed into the old ones.

    If there are no facts of the old schema in in the database we will take option 2. If the database has any fact at all of the old schema we choose option 1.

    That is, schema evolutions only take effect if there are no facts of the old schema in the database; it is ignored otherwise.

    As an example suppose we start with the following schemas:

    schema src.1 {
       predicate File {
         path : string
       }
    }

    schema os.1 {
      import src.1

      predicate Permissions {
        file : File,
        permissions : nat
      }
    }

    schema info.1 {
      import src.1

      predicate IsTemporary {
        file : File
      } F where F = src.File { path = "/tmp".. }
    }

    Now we want to make a backward-compatible change to src.File and add an extension field. We could add this to the file:

    schema src.2 {
       predicate File {
         path : string,
         extension : string
       }
    }

    schema src.2 evolves src.1

    Now if the indexer is still producing only src.1 facts, all other predicates will work as before and queries for src.File.2 will return no results.

    Once the indexer is changed to produce only src.2 facts queries like src.File.1 _ will be fulfilled using data from the src.2 schema, converting the src.File.2 results to the shape of src.File.1 before returning to the client.

    This is also the case in the derivation query of info.IsTemporary. Although info imports src.1, the query will be transformed to use src.2 facts.

    On the other hand, os.Permissions will be empty. This must be the case because its first field references a src.File.1 fact, of which there is none in the database. For this predicate to continue being available we must evolve its schema as well.

    schema os.2 {             # changed
      import src.2            # changed

      predicate Permissions {
        file : File,
        permissions : nat
      }
    }

    schema os.2 evolves os.1    # changed
    - + \ No newline at end of file diff --git a/docs/schema/design/index.html b/docs/schema/design/index.html index 353b1e896..5cbb32f70 100644 --- a/docs/schema/design/index.html +++ b/docs/schema/design/index.html @@ -5,7 +5,7 @@ Schema Design | Glean - + @@ -52,7 +52,7 @@ example of this was described in What is the difference between a predicate and a type?.

    How to experiment with schema design​

    • Generate some data and see how large it is, using :stat in the shell.

    • Write some example queries against your data, and check how much searching they do using :profile in the shell (see Query Debugging).

    - + \ No newline at end of file diff --git a/docs/schema/recursion/index.html b/docs/schema/recursion/index.html index fd644bc6f..99bd17b83 100644 --- a/docs/schema/recursion/index.html +++ b/docs/schema/recursion/index.html @@ -5,7 +5,7 @@ Recursion | Glean - + @@ -23,7 +23,7 @@ keys would make this process significantly harder.

    Facts can be recursive in their values, but not their keys. A mutually recursive set of facts must be added to the database in a single batch, however.

    To summarise, recursion is

    • allowed between predicates
    • not allowed between keys
    • allowed between values
    - + \ No newline at end of file diff --git a/docs/schema/syntax/index.html b/docs/schema/syntax/index.html index 67dff6a87..8c923430c 100644 --- a/docs/schema/syntax/index.html +++ b/docs/schema/syntax/index.html @@ -5,7 +5,7 @@ Syntax | Glean - + @@ -44,7 +44,7 @@ future. The process for safely changing schemas is described in Changing the Schema.

    schema example.2 : example.1 {
    predicate Class :
      {
           # new definition of Class
      }
    }

    Inheritance is useful for making changes to a schema by creating a new schema version:

    • Inheriting from a schema brings into scope all the types and predicates of that schema, both qualified and unqualified.
    • The new schema also exports all the types and predicates defined in the schemas it inherits from, except those that are re-defined.

    Specifically, in the above example:

    • We can import example.2 anywhere and get all the predicates defined in example.1, except that we'll get the new Class defined in example.2.
    • We can still import example.1 and get the old version of the schema.

    Note that if you have predicates that depend on a predicate that was revised in this way, you must also copy those predicates to the new schema, because the existing predicates will refer to the old version of the predicate you revised. (In due course Glean will probably provide a convenient way to do this; in the meantime you have to copy & paste. Not a big deal because you'll usually delete the old one at some point, and you can't modify it anyway.)

    Named schemas can not form cycles through their import or inheritance declarations.

    Naming rules and conventions​

    Names take the form of a dot-separated sequence of alphanumeric words. For example, sys.Blob, clang.File, or cxx.objc.Name. The words up to the last dot are the namespace, the final word is the name.

    See Names for full details.

    Briefly:

    • Namespaces (schema names) are dot-separated sequences of identifiers each beginning with a lower-case letter
    • Names and namespaces can contain only alphanumeric characters, '_', or '.' (namespaces only)
    • There is a set of reserved words that can't be used for names, e.g. class. Syncing the schema will fail with an error if you use a reserved word.
    - + \ No newline at end of file diff --git a/docs/schema/thrift/index.html b/docs/schema/thrift/index.html index 56b16d336..182de987f 100644 --- a/docs/schema/thrift/index.html +++ b/docs/schema/thrift/index.html @@ -5,7 +5,7 @@ Thrift and JSON | Glean - + @@ -20,7 +20,7 @@ shell, the results are printed as JSON-encoded Thrift; when you write data to Glean it can be in the form of JSON-encoded Thrift.

    The relationship between schema types and Thrift/JSON is given by the following table:

    Schema typeThrift typeJSON
    natNat (i64)123
    byteByte (i8)123
    stringstring"abc"
    boolbooltrue or false
    [byte]binarybase-64 encoded string *1
    [T]list<T>[...]
    {
      f₁ : T₁,
      ...,
      fₙ : Tₙ
    }    		struct Foo {
      1: T₁ f₁;
      ...
      n: Tₙ fₙ;
    }    		{
      "f₁" : q₁,
      ...
      "fₙ" : qₙ
    }
    {
      f₁ : T₁ |
      ... |
      fₙ : Tₙ
    }    		union Foo {
      1: T₁ f₁;
      ...
      n: Tₙ fₙ;
    }    		{ "f" : t }
    for one of the fields f₁..fₙ
    maybe TIn a record field:
    optional T f    		f : t
    if the value is present
    enum {
      L₁|
      ...|
      Lₙ
    }    		enum Foo {
      L₁ = 1,
      ...
      Lₙ = n
    }    		the index of the value,
    e.g. 12
    predicate P : K -> Vstruct P {
      1: Id id
      2: optional K key
      3: optional V value
    }
    note*2    		refer to fact N:
    N or { "id": N }
    define a fact:
    { "id" : N,
       "key" : t } or
    { "key": t } or
    { "key": t,
        "value" : v }
    type N = Tdepending on T:
    struct N { .. }
    union N {...}
    enum N {...}
    typedef T N;    		same as type T

    1. The Thrift encoding of a binary field in JSON is a base-64-encoded string. However, not all Thrift implementations respect this. At the time of writing, the Python Thrift implementation doesn't base-64-encode binary values. For this reason we provide an option in the Glean Thrift API to disable base-64 encoding for binary if your client doesn't support it. The Glean Shell also uses this option to make it easier to work with binary.

    2. the key is optional - a nested fact may be expanded in place or represented by a reference to the fact ID only. When querying Glean data the query specifies which nested facts should be expanded in the result, and when writing data to Glean using Thrift or JSON, we can optionally specify the value of nested facts inline.

    - + \ No newline at end of file diff --git a/docs/schema/types/index.html b/docs/schema/types/index.html index 3efda67b3..dfbf022cf 100644 --- a/docs/schema/types/index.html +++ b/docs/schema/types/index.html @@ -5,14 +5,14 @@ Built-in Types | Glean - +

    Built-in Types

    TypeMeaning
    nat64-bit natural numbers
    byte8-bit natural numbers
    stringUTF-8 encoded strings
    [T]lists of elements of type T
    { field₁ : T₁, ..., fieldₙ : Tₙ }a record with zero or more named fields
    { field₁ : T₁ | ... | fieldₙ : Tₙ }a sum (union) type with one or more named alternatives
    Pa reference to a fact of predicate P
    boolthe boolean type with values true and false
    maybe Tan optional value of type T
    enum { name₁ | ... | nameₙ }exactly one of the symbols name₁..nameₙ
    - + \ No newline at end of file diff --git a/docs/schema/workflow/index.html b/docs/schema/workflow/index.html index ab722f85b..307e92261 100644 --- a/docs/schema/workflow/index.html +++ b/docs/schema/workflow/index.html @@ -5,7 +5,7 @@ Workflow | Glean - + @@ -15,7 +15,7 @@ glean/schema/thrift, which are then processed into Haskell code by

    make thrift-schema-hs

    and finally built by

    make glean

    Examples of code using these types:

    Experimenting with schemas​

    1. Modify the source files in glean/schema/source

    2. Start up the shell locally using your schema:
      glean shell --db-root ~/local/gleandb --schema glean/schema/source
      If you don't already have a ~/local/gleandb for storing local DBs, create it with mkdir ~/local/gleandb.

    3. Test it with some example data: see Loading a DB from JSON in the shell.

    4. Iterate as necessary, using :reload in the shell to reload the schema.

    - + \ No newline at end of file diff --git a/docs/server/index.html b/docs/server/index.html index 3bcc4dbaf..40632e26a 100644 --- a/docs/server/index.html +++ b/docs/server/index.html @@ -5,7 +5,7 @@ Running the Glean Server | Glean - + @@ -17,7 +17,7 @@ Port number to listen on.

    The server watches for changes in any configuration files specified with config:PATH, including the schema.

    - + \ No newline at end of file diff --git a/docs/shell/index.html b/docs/shell/index.html index e8329073e..12dafd55a 100644 --- a/docs/shell/index.html +++ b/docs/shell/index.html @@ -5,7 +5,7 @@ Using the Shell | Glean - + @@ -55,7 +55,7 @@ test your changes.
  • :statistics [PREDICATE]
    Show statistics for the current database.
  • :quit
    Leave the shell.
    • - + \ No newline at end of file diff --git a/docs/trying/index.html b/docs/trying/index.html index b0d589bc1..7b8f32973 100644 --- a/docs/trying/index.html +++ b/docs/trying/index.html @@ -5,7 +5,7 @@ Trying Glean | Glean - + @@ -28,7 +28,7 @@ (http://localhost:8888/packages/react-dom/src/client/ReactDOMComponent.js) - note how Glean is accurately linking both local and imported symbols.

    - + \ No newline at end of file diff --git a/docs/walkthrough/index.html b/docs/walkthrough/index.html index f3651f244..dbd36ff93 100644 --- a/docs/walkthrough/index.html +++ b/docs/walkthrough/index.html @@ -5,7 +5,7 @@ Walkthrough | Glean - + @@ -22,7 +22,7 @@ in /tmp/glean/facts.glean. Then reload schema and create a database from the example data using :reload and :load <file> in the shell:

    > :reload
    reloading schema [2 schemas, 7 predicates]
    > :load /tmp/glean/facts.glean
    facts>

    Now head over to Angle Guide to try some example queries and learn about how the query language works.

    - + \ No newline at end of file diff --git a/docs/write/index.html b/docs/write/index.html index 5a251758e..20618c4b2 100644 --- a/docs/write/index.html +++ b/docs/write/index.html @@ -5,7 +5,7 @@ Writing data to Glean | Glean - + @@ -22,7 +22,7 @@ have dependencies between them, so the server won't hand out a task until its dependencies are complete.

  • When all tasks are done, the server marks the database as complete.

    • APIs for writing​

    If none of the above work for you, the Thrift API enable basic write access to the database.

    • kickOff can be used to create a new DB
    • sendJsonBatch is for sending facts in JSON-serialized form
    • finishBatch exposes the result of a previously sent JSON batch
    • workFinished closes a DB

    A rough outline of a client looks like:

    glean = make_glean_thrift_client()
    db_handle = make_uuid()
    glean.kickOff(my_repo, KickOffFill(writeHandle=db_handle))
    for json_batch in json_batches:
        handle = glean.sendJsonBatch(json_batch)
        result = glean.finishBatch(handle)
        # handle result
    glean.workFinished(my_repo, db_handle, success_or_failure)

    Writing from the command line​

    JSON format​

    The JSON format for Glean data is described in Thrift and JSON.

    Here's an example of JSON data for writing to Glean:

    [
      { "predicate": "cxx1.Name.1",          # define facts for cxx1.Name.1
        "facts": [
          { "id": 1, "key": "abc" },         # define a fact with id 1
          { "id": 2, "key": "def" }
        ]
      },
      { "predicate": "cxx1.FunctionName.1",  # define facts for cxx1.FunctionName.1
        "facts": [
          { "id": 3,
            "key": {
              "name": { "id": 1 }}}          # reference to fact with id 1
        ]
      },
      { "predicate": "cxx1.FunctionQName.1", # define facts for cxx1.FunctionQName.1
        "facts": [
          { "key": {
            "name": 3,                       # 3 is shorthand for { "id": 3 }
            "scope": { "global_": {} } } },
          { "key": {
            "name": {
              "key": {                       # define a nested fact directly
                "name": {
                  "key": "ghi" }}},         # another nested fact
            "scope": {
              "namespace_": {
                "key": {
                  "name": {
                    "key": "std" }}}}}
        ]
      }
    ]

    The rules of the game are:

    • Predicate names must include versions, i.e. cxx1.Name.1 rather than cxx1.Name.
    • The id field when defining a fact is optional. The id numbers in the input file will not be the final id numbers assigned to the facts in the database.
    • There are no restrictions on id values (any 64-bit integer will do) but an id value may not be reused within a file.
    • Later facts may refer to earlier ones using either { "id": N } or just N.
    • It is only possible to refer to ids from facts in the same file, if you are writing multiple files using glean write or via the sendJsonBatch API.
    • a nested facts can be defined inline, instead of defining it with an id first and then referencing it.
    • an inline nested fact can be given an id and referred to later.

    Loading a DB from JSON in the shell​

    The shell is useful for experimenting with creating a DB from JSON data directly. Let's try loading the data above into a DB in the shell:

    $ mkdir /tmp/glean
    $ glean shell --db-root /tmp/glean
    Glean Shell, dev mode
    type :help for help.
    no fbsource database availabe
    > :load test/0 /home/smarlow/test
    I0514 01:19:37.137109 3566745 Work.hs:184] test/16: database complete

    Let's see what facts we loaded:

    test> :stat
    1
      count: 72
      size:  5988
    cxx1.FunctionName.1
      count: 2
      size:  66
    cxx1.FunctionQName.1
      count: 2
      size:  70
    cxx1.Name.1
      count: 4
      size:  148
    cxx1.NamespaceQName.1
      count: 1
      size:  35
    test>

    Note that there were 4 cxx1.Name.1 facts - some of those were defined as inline nested facts in the JSON. We can query them all:

    test> cxx1.Name _
    4 results, 1 queries, 4 facts, 0.22ms, 44296 bytes

    { "id": 1096, "key": "abc" }
    { "id": 1097, "key": "def" }
    { "id": 1100, "key": "ghi" }
    { "id": 1102, "key": "std" }

    Note that the id values here do not correspond to the id values in the input file.

    Creating a database using the command line​

    The glean command-line tool can be used to create a database directly on the server.

    To create a database from a single file of JSON facts:

    glean create --service <write-server> --finish --db <name>/<instance> <filename>

    where

    • <write-server> is the host:port of the Glean server
    • <name> is the name for your DB. For indexing repositories we normally use the name of the repository, but it's just a string, so you can use whatever you want.
    • <hash> identifies this particular instance of your database. For repositories we normally use the revision hash, but, again, it's just a string.
    • <filename> the file containing the JSON facts.

    If the file is more than, say, 100MB, this operation will probably time out sending the data to the server. To send large amounts of data you need to batch it up into multiple files, and then send it like this:

    glean create --service <write-server> --db <name>/<hash>
    glean write --service <write-server> --db <name>/<hash> <filename1>
    glean write --service <write-server> --db <name>/<hash> <filename2>
    ...
    glean finish --service <write-server> --db <name>/<hash>

    To find out if your DB made it:

    glean shell --service <write-server> :list

    This will list the DBs available on the write server.

    - + \ No newline at end of file diff --git a/index.html b/index.html index f3292430a..9de7dc8a5 100644 --- a/index.html +++ b/index.html @@ -5,14 +5,14 @@ Glean | Glean - +
    Glean Logo

    Glean

    System for collecting, deriving and querying facts about source code

    Get Started

    Key Features

    Rich types

    Store detailed information about code

    Compact storage

    Store data about code at scale

    Efficient queries

    Build experiences with deep insights from code

    - + \ No newline at end of file