789fb25 · project-m36 · git.iko.soy

git.iko.soy/project-m36

patch docs to include new isomorphic schema prompt entry

resolves #60

commit789fb25d021e7ff2b530620d0c5bee9beba46215 authorAgentM <agentm@themactionfaction.com> dateWed 30 Nov 2016, 22:11 (10 years ago) parent585420a

10 files changed+93−97

compare with master

unifiedsplit

docs/15_minute_tutorial.markdown+25−25 docs/atomfunctions.markdown+1−1 docs/merge_transactions.markdown+8−8 docs/new_datatypes.markdown+3−3 docs/on_null.markdown+4−4 docs/reaching_out_of_the_tarpit.markdown+2−2 docs/transaction_graph_operators.markdown+7−11 docs/transgraphrelationalexpr.markdown+4−4 docs/tutd_tutorial.markdown+31−31 docs/using_notifications.markdown+8−8

docs/15_minute_tutorial.markdown+25−25

@@ -26,13 +26,13 @@ Note that TutorialD is strongly-typed- no type coercions take place automaticall

2626### Load the Canonical Chris Date Example

2727

2828```

29−TutorialD (master): :importexample date

29+TutorialD (master/main): :importexample date

3030```

3131

3232or

3333

3434```

35−TutorialD (master): :importtud "scripts/DateExamples.tutd"

35+TutorialD (master/main): :importtud "scripts/DateExamples.tutd"

3636```

3737

3838```:importtutd``` (do not skip typing the preceding colon), loads a file which contains a script written in the TutorialD dialect used by Project:M36 and executes it to change the state of the database. In this case, the relations "s" (supplier), "p" (product), and "sp" (suppliers-products) are now loaded.

@@ -42,7 +42,7 @@ TutorialD (master): :importtud "scripts/DateExamples.tutd"

4242### Execute Relational Expressions

4343

4444```

45−TutorialD (master): :showexpr s

45+TutorialD (master/main): :showexpr s

4646┌──────────┬────────┬───────────┬───────────┐

4747│city::Text│s#::Text│sname::Text│status::Int│

4848├──────────┼────────┼───────────┼───────────┤

@@ -63,7 +63,7 @@ You will need to [learn TutorialD](/docs/tutd_tutorial.markdown) to create relat

6363#### Joins

6464

6565```

66−TutorialD (master): :showexpr s join sp

66+TutorialD (master/main): :showexpr s join sp

6767┌──────────┬────────┬────────┬────────┬───────────┬───────────┐

6868│city::Text│p#::Text│qty::Int│s#::Text│sname::Text│status::Int│

6969├──────────┼────────┼────────┼────────┼───────────┼───────────┤

@@ -86,7 +86,7 @@ All joins in TutorialD are similar to "NATURAL JOIN" in SQL.

8686#### Restriction

8787

8888```

89−TutorialD (master): :showexpr s where status=20

89+TutorialD (master/main): :showexpr s where status=20

9090┌──────────┬────────┬───────────┬───────────┐

9191│city::Text│s#::Text│sname::Text│status::Int│

9292├──────────┼────────┼───────────┼───────────┤

@@ -100,7 +100,7 @@ Restrictions are similar to the "WHERE" clause in SQL.

100100#### Projection

101101

102102```

103−TutorialD (master): :showexpr p{color,p#,weight}

103+TutorialD (master/main): :showexpr p{color,p#,weight}

104104┌───────────┬────────┬───────────┐

105105│color::Text│p#::Text│weight::Int│

106106├───────────┼────────┼───────────┤

@@ -118,7 +118,7 @@ Projection is equivalent to "SELECT <columns>" in SQL.

118118#### Attribute Rename

119119

120120```

121−TutorialD (master): :showexpr s rename {city as town}

121+TutorialD (master/main): :showexpr s rename {city as town}

122122┌────────┬───────────┬───────────┬──────────┐

123123│s#::Text│sname::Text│status::Int│town::Text│

124124├────────┼───────────┼───────────┼──────────┤

@@ -139,7 +139,7 @@ The relational algebra includes two fundamental named relations: "true" and "fal

139139"true" is the name of the relation with no attributes and a set of one tuple of no attributes.

140140

141141```

142−TutorialD (master): :showexpr true

142+TutorialD (master/main): :showexpr true

143143┌┐

144144││

145145├┤

@@ -149,7 +149,7 @@ TutorialD (master): :showexpr true

149149"false" is the name of the relation with no attributes and an empty tuples set.

150150

151151```

152−TutorialD (master): :showexpr false

152+TutorialD (master/main): :showexpr false

153153┌┐

154154││

155155└┘

@@ -164,8 +164,8 @@ Database context expressions change the state of the database, much like "CREATE

164164#### Create a Relation Variable

165165

166166```

167−TutorialD (master): x:=relation{name Text, age Int}{tuple{name "Steve", age 40},tuple{name "Mike", age 31}}

168−TutorialD (master): :showexpr x

167+TutorialD (master/main): x:=relation{name Text, age Int}{tuple{name "Steve", age 40},tuple{name "Mike", age 31}}

168+TutorialD (master/main): :showexpr x

169169┌────────┬──────────┐

170170│age::Int│name::Text│

171171├────────┼──────────┤

@@ -179,16 +179,16 @@ This is similar to SQL's "CREATE TABLE" operator.

179179#### Insert Additional Tuples

180180

181181```

182−TutorialD (master): x:=relation{name Text, age Int}{tuple{name "Steve", age 40},tuple{name "Mike", age 31}}

183−TutorialD (master): :showexpr x

182+TutorialD (master/main): x:=relation{name Text, age Int}{tuple{name "Steve", age 40},tuple{name "Mike", age 31}}

183+TutorialD (master/main): :showexpr x

184184┌────────┬──────────┐

185185│age::Int│name::Text│

186186├────────┼──────────┤

187187│40 │"Steve" │

188188│31 │"Mike" │

189189└────────┴──────────┘

190−TutorialD (master): insert x relation{tuple{name "Bob", age 24}}

191−TutorialD (master): :showexpr x

190+TutorialD (master/main): insert x relation{tuple{name "Bob", age 24}}

191+TutorialD (master/main): :showexpr x

192192┌────────┬──────────┐

193193│age::Int│name::Text│

194194├────────┼──────────┤

@@ -203,7 +203,7 @@ Note that the relational insertion is identical to "x:=x union relation{...}".

203203#### Update Tuples in a Relation Variable

204204

205205```

206−TutorialD (master): :showexpr s

206+TutorialD (master/main): :showexpr s

207207┌──────────┬────────┬───────────┬───────────┐

208208│city::Text│s#::Text│sname::Text│status::Int│

209209├──────────┼────────┼───────────┼───────────┤

@@ -213,8 +213,8 @@ TutorialD (master): :showexpr s

213213│"London" │"S4" │"Clark" │20 │

214214│"Athens" │"S5" │"Adams" │30 │

215215└──────────┴────────┴───────────┴───────────┘

216−TutorialD (master): update s where city="London" (status:=35)

217−TutorialD (master): :showexpr s

216+TutorialD (master/main): update s where city="London" (status:=35)

217+TutorialD (master/main): :showexpr s

218218┌──────────┬────────┬───────────┬───────────┐

219219│city::Text│s#::Text│sname::Text│status::Int│

220220├──────────┼────────┼───────────┼───────────┤

@@ -228,7 +228,7 @@ TutorialD (master): :showexpr s

228228#### Deleting Tuples from a Relation Variable

229229

230230```

231−TutorialD (master): :showexpr s

231+TutorialD (master/main): :showexpr s

232232┌──────────┬────────┬───────────┬───────────┐

233233│city::Text│s#::Text│sname::Text│status::Int│

234234├──────────┼────────┼───────────┼───────────┤

@@ -238,8 +238,8 @@ TutorialD (master): :showexpr s

238238│"London" │"S4" │"Clark" │20 │

239239│"Athens" │"S5" │"Adams" │30 │

240240└──────────┴────────┴───────────┴───────────┘

241−TutorialD (master): delete s where sname="Adams"

242−TutorialD (master): :showexpr s

241+TutorialD (master/main): delete s where sname="Adams"

242+TutorialD (master/main): :showexpr s

243243┌──────────┬────────┬───────────┬───────────┐

244244│city::Text│s#::Text│sname::Text│status::Int│

245245├──────────┼────────┼───────────┼───────────┤

@@ -257,19 +257,19 @@ Unlike typical SQL DBMSs, Project:M36 maintains a graph of transactions, similar

257257#### Committing

258258

259259```

260−TutorialD (master): :commit

260+TutorialD (master/main): :commit

261261```

262262

263263#### Rollback

264264

265265```

266−TutorialD (master): :rollback

266+TutorialD (master/main): :rollback

267267```

268268

269269#### Branching

270270

271271```

272−TutorialD (master): :branch experimental

272+TutorialD (master/main): :branch experimental

273273TutorialD (experimental): employee:=relation{name Text, salary Int}

274274TutorialD (experimental): :commit

275275```

@@ -280,7 +280,7 @@ Note how the prompt changes to reflect the current branch's name.

280280

281281```

282282TutorialD (experimental): :jumphead master

283−TutorialD (master): :showexpr employee

283+TutorialD (master/main): :showexpr employee

284284ERR: RelVarNotDefinedError "employee"

285285```

286286

docs/atomfunctions.markdown+1−1

@@ -15,7 +15,7 @@ In this example, we install an atom function to convert between Fahrenheit and C

1515We write the function giving it the name "celsiusToFahrenheit" with type ```Int -> Int``` which indicates to the compiler that the function take one ```Int``` argument value and returns one ```Int``` value. Finally, the body of the function is implemented in quotes or triple-quotes. Note that the function makes use of the "[ProjectM36.Base](/src/lib/ProjectM36/Base.hs)" module to handle the Atom type. The function must take a list of Atoms as arguments and return an Atom. The standard GHC Prelude is available in this AtomFunctionBody context.

1616

1717```

18−TutorialD (master): addatomfunction "celsiusToFahrenheit" Int -> Int """\((IntAtom c):_) -> IntAtom ( (c * 9 `div` 5) + 32)"""

18+TutorialD (master/main): addatomfunction "celsiusToFahrenheit" Int -> Int """\((IntAtom c):_) -> IntAtom ( (c * 9 `div` 5) + 32)"""

1919```

2020

2121Using triple-quotes allows quotes to be used inside the string without backslash escaping, which can become tedious.

docs/merge_transactions.markdown+8−8

@@ -58,7 +58,7 @@ Branching and merging are built-in to the Project:M36 ```tutd``` client.

5858

5959First, let's create a new branch for some new sales data.

6060```

61−TutorialD (master): :branch add_sales_feature

61+TutorialD (master/main): :branch add_sales_feature

6262TutorialD (add_sales_feature):

6363```

6464

@@ -82,15 +82,15 @@ Now, the relation variable "sales" is available on the "add_sales_feature" branc

8282

8383```

8484TutorialD (add_sales_feature): :jumphead master

85−TutorialD (master): :showexpr sales

85+TutorialD (master/main): :showexpr sales

8686ERR: RelVarNotDefinedError "sales"

8787```

8888

8989Now that we are on the "master" branch, let's add a relation variables unrelated to sales.

9090

9191```

92−TutorialD (master): employees := relation{tuple{name "Steve"},tuple{name "Cindy"}}

93−TutorialD (master): :commit

92+TutorialD (master/main): employees := relation{tuple{name "Steve"},tuple{name "Cindy"}}

93+TutorialD (master/main): :commit

9494```

9595

9696Note that the "employees" relation variable is only available on the "master" branch and not on the "add_sales_feature" branch.

@@ -98,7 +98,7 @@ Note that the "employees" relation variable is only available on the "master" br

9898Let's look at the transaction graph:

9999

100100```

101−TutorialD (master): :showgraph

101+TutorialD (master/main): :showgraph

102102┌─────────────┬───────────────────┬──────────────────────────────────────┬────────────────────────────────────────┐

103103│current::Bool│head::Text │id::Text │parents::relation {id::Text} │

104104├─────────────┼───────────────────┼──────────────────────────────────────┼────────────────────────────────────────┤

@@ -129,15 +129,15 @@ TutorialD (master): :showgraph

129129Now, imagine that the work on the "add_sales_merge" branch is complete, so we will merge the "add_sales_feature" branch back into the "master" branch. We say we are merging "back" because both branches share a common ancestor transaction.

130130

131131```

132−TutorialD (master): :mergetrans union add_sales_feature master

133−TutorialD (master): :showexpr employees

132+TutorialD (master/main): :mergetrans union add_sales_feature master

133+TutorialD (master/main): :showexpr employees

134134┌──────────┐

135135│name::Text│

136136├──────────┤

137137│"Steve" │

138138│"Cindy" │

139139└──────────┘

140−TutorialD (master): :showexpr sales

140+TutorialD (master/main): :showexpr sales

141141┌───────────┬─────────────┐

142142│amount::Int│product::Text│

143143├───────────┼─────────────┤

docs/new_datatypes.markdown+3−3

@@ -13,8 +13,8 @@ Project:M36 makes it easy to add any Haskell data type to the database. Any type

1313Use the ```tutd``` interpreter to create new type and data constructors with essentially the same syntax as in Haskell:

1414

1515```

16−TutorialD (master): data Hair = Bald | Brown | Blond | OtherColor Text

17−TutorialD (master): :showexpr relation{tuple{name "Steve", hair Blond}, tuple{name "Sam", hair OtherColor "Grey"}}

16+TutorialD (master/main): data Hair = Bald | Brown | Blond | OtherColor Text

17+TutorialD (master/main): :showexpr relation{tuple{name "Steve", hair Blond}, tuple{name "Sam", hair OtherColor "Grey"}}

1818┌─────────────────┬──────────┐

1919│hair::Hair │name::Text│

2020├─────────────────┼──────────┤

@@ -28,7 +28,7 @@ SQL's enumerations or even joins do not compare favorably to a genuine algebraic

2828Types can be forgotten as well:

2929

3030```

31−TutorialD (master): undata Hair

31+TutorialD (master/main): undata Hair

3232```

3333

3434These runtime types can therefore change between transactions. Note that the underlying data values do not change when the types change. Once changed, only new values will reflect the new data constructors.

docs/on_null.markdown+4−4

@@ -347,8 +347,8 @@ But all we have really done is add even more NULLs. Retrieving a sensible value

347347Project:M36 supports management of new algebraic data types at runtime. These types are associated with transactions and can changed over time whereas primitive Atoms cannot be changed.

348348d

349349```

350−TutorialD (master): data Age = PreciseAge Int | ForgotToAsk | RefusedToDisclose | NotApplicable | ApproximateAge Int Int

351−TutorialD (master): :showexpr relation{tuple{name "Steve", age ApproximateAge 20 30}, tuple{name "Bob", age RefusedToDisclose}, tuple {name "Initech Corp.", age NotApplicable}}

350+TutorialD (master/main): data Age = PreciseAge Int | ForgotToAsk | RefusedToDisclose | NotApplicable | ApproximateAge Int Int

351+TutorialD (master/main): :showexpr relation{tuple{name "Steve", age ApproximateAge 20 30}, tuple{name "Bob", age RefusedToDisclose}, tuple {name "Initech Corp.", age NotApplicable}}

352352┌────────────────────┬───────────────┐

353353│age::Age │name::Text │

354354├────────────────────┼───────────────┤

@@ -361,8 +361,8 @@ TutorialD (master): :showexpr relation{tuple{name "Steve", age ApproximateAge 20

361361Note that the two values which would normally be rendered as NULL in SQL are indeed proper values and can be distinguished. Three-valued logic makes no appearance. The type constructors can also have arguments:

362362

363363```

364−TutorialD (master): data Tree a = Node a (Tree a) (Tree a) | EmptyNode

365−TutorialD (master): :showexpr relation{tuple{family "Stevenson", familytree Node "Jim" (Node "Cindy" EmptyNode EmptyNode) (Node "Mike" EmptyNode EmptyNode)}}

364+TutorialD (master/main): data Tree a = Node a (Tree a) (Tree a) | EmptyNode

365+TutorialD (master/main): :showexpr relation{tuple{family "Stevenson", familytree Node "Jim" (Node "Cindy" EmptyNode EmptyNode) (Node "Mike" EmptyNode EmptyNode)}}

366366┌────────────┬───────────────────────────────────────────────────────────────────────────────┐

367367│family::Text│familytree::Tree (a::Text) │

368368├────────────┼───────────────────────────────────────────────────────────────────────────────┤

docs/reaching_out_of_the_tarpit.markdown+2−2

@@ -58,8 +58,8 @@ Project:M36 implements multiple interfaces:

5858To understand how Project:M36 stacks up against the fictional programming language shown in the paper, we have implemented the [example from the paper](/examples/out_of_the_tarpit.tutd). The language used in the script is a dialect of Chris Date's TutorialD language. It can be loaded into an interactive ```tutd``` session like so:

5959

6060```

61−TutorialD (master): :importexample date

62−TutorialD (master): :showexpr p

61+TutorialD (master/main): :importexample date

62+TutorialD (master/main): :showexpr p

6363┌───────────────────┬────────────┬───────────────────┬────────────┬────────────┐

6464│address::Address │agent::Agent│dateRegistered::Day│photo::Text │price::Price│

6565├───────────────────┼────────────┼───────────────────┼────────────┼────────────┤

docs/transaction_graph_operators.markdown+7−11

@@ -37,7 +37,7 @@ Note that this transaction graph approach is different from that of most SQL DBM

3737To convert a mutable database context into a transaction, it must be "committed" to the transaction graph. The equivalent in SQL is COMMIT.

3838

3939```

40−TutorialD (master): :commit

40+TutorialD (master/main): :commit

4141```

4242

4343Once committed, the transaction's database context becomes immutable. Internally, Project:M36 uniquely identifies each transaction with a UUID.

@@ -47,7 +47,7 @@ Once committed, the transaction's database context becomes immutable. Internally

4747Sometimes, the user determines that the changes in the mutable database context can be discarded and the context reset to be a copy of its parent's transaction. This is called a "rollback" because it rolls back to a previous known state. The equivalent in SQL is ROLLBACK.

4848

4949```

50−TutorialD (master): :rollback

50+TutorialD (master/main): :rollback

5151```

5252

5353#### Show Transaction Graph

@@ -55,7 +55,7 @@ TutorialD (master): :rollback

5555In order to navigate the transaction graph, one must specify transaction UUIDs. Viewing the entirety of the transaction graph as a relation is a single command.

5656

5757```

58−TutorialD (master): :showgraph

58+TutorialD (master/main): :showgraph

5959┌───────┬──────┬────────────────────────────────────┬───────┐

6060│current│head │id │parents│

6161├───────┼──────┼────────────────────────────────────┼───────┤

@@ -75,7 +75,7 @@ The "parents" attribute is a subrelation holding all parent transaction UUIDs fo

7575A new branch can be create from any point in the transaction. A branch associates a human-readable name with a set of transactions diverging from a parent transaction. After a branch, there are two heads to which one could commit.

7676

7777```

78−TutorialD (master): :branch testing_data_2005

78+TutorialD (master/main): :branch testing_data_2005

7979TutorialD (testing_data_2005):

8080```

8181

@@ -89,7 +89,7 @@ Note that jumping to another head implies losing any changes in the current data

8989

9090```

9191TutorialD (testing_data_2005): :jumphead master

92−TutorialD (master):

92+TutorialD (master/main):

9393```

9494

9595Further commits will be added to the target branch.

@@ -104,12 +104,8 @@ Instead of jumping to the head of a branch for the purpose of adding more commit

104104If one jumps to a non-head transaction, committing new transactions are no longer possible because the past transactions cannot be overwritten.

105105

106106```

107−TutorialD (master): :jump 11b601c9-f46b-42b0-a2ce-cf18ced31b7f

108−TutorialD (11b601c9-f46b-42b0-a2ce-cf18ced31b7f):

107+TutorialD (master/main): :jump 11b601c9-f46b-42b0-a2ce-cf18ced31b7f

108+TutorialD (11b601c9-f46b-42b0-a2ce-cf18ced31b7f):

109109```

110110

111111Note that the ```tutd``` prompt now indicates that the mutable database context now refers to a specific transaction by UUID.

112−

113−

114−

115−

docs/transgraphrelationalexpr.markdown+4−4

@@ -18,10 +18,10 @@ In practice, trans-graph relational expressions are very similar to normal relat

1818

1919In ```tutd```, here are two equivalent queries (assuming that ```s``` and ```sp``` are relation variables which have been committed to the ```master``` branch):

2020```

21−TutorialD (master): :showexpr s join sp

21+TutorialD (master/main): :showexpr s join sp

2222```

2323```

24−TutorialD (master): :showtransgraphexpr s@master join sp@master

24+TutorialD (master/main): :showtransgraphexpr s@master join sp@master

2525```

2626

2727Note that the only difference is that the second expression explicitly references which transaction the relation variable is referencing. In the first relational expression, this marker is implicit because the query can only reference the current in-flight transaction.

@@ -29,7 +29,7 @@ Note that the only difference is that the second expression explicitly reference

2929Naturally, the trans-graph relational expression is most useful when querying across multiple transactions. This can be accomplished by specifying the transaction id (UUID) or using head name backtracking which is intentionally similar to the git traversal syntax.

3030

3131```

32−TutorialD (master): :showtransgraphexpr s@master~ join sp@master

32+TutorialD (master/main): :showtransgraphexpr s@master~ join sp@master

3333```

3434

3535The transaction marker ```master~``` indicates that we wish to reference the first parent of the transaction at the head of the "master" branch. Then, we wish to join it with the relation variable ```sp``` at the head transaction of the master branch. Thusly, we can join two relations from two different transactions.

@@ -39,7 +39,7 @@ Since transactions can have multiple parents due to merge commits, the ```^x```

3939These markers can be freely mixed to traverse the graph from a head, as in the following example:

4040

4141```

42−TutorialD (master): :showtransgraphexpr s@improveheadlights~^2

42+TutorialD (master/main): :showtransgraphexpr s@improveheadlights~^2

4343```

4444

4545This query asks to return relation variable ```s``` at the transaction context from the second parent of the first parent of the head of the "improveheadlights" branch.

docs/tutd_tutorial.markdown+31−31

@@ -9,7 +9,7 @@ It is presumed that the audience for this tutorial has at least some minimal bac

99From the project-m36 source directory, execute ```cabal run tutd``` to start the interactive TutorialD interpreter. You will be greeted by the interactive prompt:

1010

1111```

12−TutorialD (master):

12+TutorialD (master/main):

1313```

1414

1515"master" refers to the name of the branch to which the current transaction will be potentially committing.

@@ -32,7 +32,7 @@ With regards to boolean values, be sure not to conflate ```t``` or ```f``` as a

3232Project:M36 will complain loudly if the expected types do not match. Automatic type coercion does not exist.

3333

3434```

35−TutorialD (master): :showexpr S:{more:=add(10,@sname)}

35+TutorialD (master/main): :showexpr S:{more:=add(10,@sname)}

3636ERR: AtomFunctionTypeError "add" 2 IntAtomType StringAtomType

3737```

3838

@@ -84,7 +84,7 @@ Each section assumes a fresh instance of the Date examples. The relation variabl

8484A relational expression combines relational operators to create a new relation. ```tutd``` can display the result of executing a relational expression with ":showexpr".

8585

8686```

87−TutorialD (master): :showexpr p

87+TutorialD (master/main): :showexpr p

8888┌──────┬─────┬──┬─────┬──────┐

8989│city │color│p#│pname│weight│

9090├──────┼─────┼──┼─────┼──────┤

@@ -100,7 +100,7 @@ TutorialD (master): :showexpr p

100100To show all relation variables in the current session, use ```:showrelvars```:

101101

102102```

103−TutorialD (master): :showrelvars

103+TutorialD (master/main): :showrelvars

104104┌─────────────────────────────────────────────────┬──────────┐

105105│attributes::relation {attribute::Text,type::Text}│name::Text│

106106├─────────────────────────────────────────────────┼──────────┤

@@ -146,7 +146,7 @@ Relational operators generate new relations from existing relations. The operato

146146The unary rename operator outputs a new relation with chosen attributes renamed. In SQL, the equivalent is to use "AS" in the column name list of SELECTS.

147147

148148```

149−TutorialD (master): :showexpr s rename {city as town}

149+TutorialD (master/main): :showexpr s rename {city as town}

150150┌──┬─────┬──────┬──────┐

151151│s#│sname│status│town │

152152├──┼─────┼──────┼──────┤

@@ -165,7 +165,7 @@ Projection is applied by adding curly braces and attribute names following a rel

165165For example:

166166

167167```

168−TutorialD (master): :showexpr p{color,city}

168+TutorialD (master/main): :showexpr p{color,city}

169169┌──────┬─────┐

170170│city │color│

171171├──────┼─────┤

@@ -181,7 +181,7 @@ TutorialD (master): :showexpr p{color,city}

181181Restriction is applied using a "where" clause, much like in SQL.

182182

183183```

184−TutorialD (master): :showexpr p where color="Blue" and city="Paris"

184+TutorialD (master/main): :showexpr p where color="Blue" and city="Paris"

185185┌─────┬─────┬──┬─────┬──────┐

186186│city │color│p#│pname│weight│

187187├─────┼─────┼──┼─────┼──────┤

@@ -192,7 +192,7 @@ TutorialD (master): :showexpr p where color="Blue" and city="Paris"

192192The restriction predicate can be built from "and", "not", and "or". Boolean atom functions can also appear in a restriction as long as they are preceded by "^". For example:

193193

194194```

195−TutorialD (master): :showexpr s where ^lt(@status,20)

195+TutorialD (master/main): :showexpr s where ^lt(@status,20)

196196┌─────┬──┬─────┬──────┐

197197│city │s#│sname│status│

198198├─────┼──┼─────┼──────┤

@@ -205,7 +205,7 @@ TutorialD (master): :showexpr s where ^lt(@status,20)

205205Joins are binary operators and are applied with the "join" keyword. The equivalent in SQL would be a "NATURAL JOIN". To join attributes which are not identically-named, use the rename operator

206206

207207```

208−TutorialD (master): :showexpr s join sp

208+TutorialD (master/main): :showexpr s join sp

209209┌──────┬──┬───┬──┬─────┬──────┐

210210│city │p#│QTY│s#│sname│status│

211211├──────┼──┼───┼──┼─────┼──────┤

@@ -228,7 +228,7 @@ TutorialD (master): :showexpr s join sp

228228The binary union operator merges tuples from both relations if-and-only-if the attributes of both relations are identical. The SQL equivalent is the "UNION" operator. Unlike SQL, however, duplicate tuples are not tolerated, so there is no "UNION ALL" equivalent in the relational algebra.

229229

230230```

231−TutorialD (master): :showexpr S union S

231+TutorialD (master/main): :showexpr S union S

232232┌──────┬──┬─────┬──────┐

233233│city │s#│sname│status│

234234├──────┼──┼─────┼──────┤

@@ -247,7 +247,7 @@ The union of any relation with itself is itself.

247247The extend unary operator adds an attribute to a relation's header and body and is represented by a colon ":". The equivalent in SQL is a subselect in a SELECT column list. Typically, extend is used to add information derived from relation.

248248

249249```

250−TutorialD (master): :showexpr s:{status2:=add(10,@status)}

250+TutorialD (master/main): :showexpr s:{status2:=add(10,@status)}

251251┌──────┬──┬─────┬──────┬───────┐

252252│city │s#│sname│status│status2│

253253├──────┼──┼─────┼──────┼───────┤

@@ -279,7 +279,7 @@ The unary group operator groups the argument attributes into subrelations for ea

279279Grouping is useful for aggregate operations (see below) or for summarizing data against a set of attributes; for example, "display all employees grouped by boss name".

280280

281281```

282−TutorialD (master): :showexpr s group ({sname,status,s#} as subrel)

282+TutorialD (master/main): :showexpr s group ({sname,status,s#} as subrel)

283283┌──────┬─────────────────┐

284284│city │subrel │

285285├──────┼─────────────────┤

@@ -308,7 +308,7 @@ TutorialD (master): :showexpr s group ({sname,status,s#} as subrel)

308308The unary ungroup operator "unwraps" subrelations in a relation-valued attribute. There is no equivalent in SQL.

309309

310310```

311−TutorialD (master): :showexpr (s group ({sname,status,s#} as subrel)) ungroup subrel

311+TutorialD (master/main): :showexpr (s group ({sname,status,s#} as subrel)) ungroup subrel

312312┌──────┬──┬─────┬──────┐

313313│city │s#│sname│status│

314314├──────┼──┼─────┼──────┤

@@ -331,8 +331,8 @@ While relational operators compose to relational expressions representing querie

331331The relation variable assignment mentioned above certainly changes the state of the database.

332332

333333```

334−TutorialD (master): newrelvar:=relation{tuple{age 3}}

335−TutorialD (master): :showexpr newrelvar

334+TutorialD (master/main): newrelvar:=relation{tuple{age 3}}

335+TutorialD (master/main): :showexpr newrelvar

336336┌───┐

337337│age│

338338├───┤

@@ -347,8 +347,8 @@ All further operators are convenience operators and could be implemented with si

347347To signal that a relation variable should be forgotten, undefine it.

348348

349349```

350−TutorialD (master): undefine s

351−TutorialD (master): :showexpr s

350+TutorialD (master/main): undefine s

351+TutorialD (master/main): :showexpr s

352352ERR: RelVarNotDefinedError "s"

353353```

354354

@@ -357,8 +357,8 @@ ERR: RelVarNotDefinedError "s"

357357The insert operators accepts a relation variable and a relation of the same type (a relation having an identical header), and replaces the relation referenced by the relation variable with the union of the previous relation value and the argument's relation value.

358358

359359```

360−TutorialD (master): insert s relation{tuple{city "Boston",s# "S10",sname "Gonzalez",status 10}}

361−TutorialD (master): :showexpr s

360+TutorialD (master/main): insert s relation{tuple{city "Boston",s# "S10",sname "Gonzalez",status 10}}

361+TutorialD (master/main): :showexpr s

362362┌──────┬───┬────────┬──────┐

363363│city │s# │sname │status│

364364├──────┼───┼────────┼──────┤

@@ -381,8 +381,8 @@ s:=s union relation{tuple{city "Boston",s# "S10",sname "Gonzalez",status 10}}

381381The update operator accepts a relation argument and a predicate, optionally filters and creates new tuples based on the original relation.

382382

383383```

384−TutorialD (master): update s where status=20 (sname:="Mr. Twenty")

385−TutorialD (master): :showexpr s

384+TutorialD (master/main): update s where status=20 (sname:="Mr. Twenty")

385+TutorialD (master/main): :showexpr s

386386┌──────┬──┬──────────┬──────┐

387387│city │s#│sname │status│

388388├──────┼──┼──────────┼──────┤

@@ -397,8 +397,8 @@ TutorialD (master): :showexpr s

397397This is logically equivalent to:

398398

399399```

400−TutorialD (master): s:=(((s where status=20){city,s#,status}):{sname:="Mr. Twenty"}) union (s where not status=20)

401−TutorialD (master): :showexpr s

400+TutorialD (master/main): s:=(((s where status=20){city,s#,status}):{sname:="Mr. Twenty"}) union (s where not status=20)

401+TutorialD (master/main): :showexpr s

402402┌──────┬──┬──────────┬──────┐

403403│city │s#│sname │status│

404404├──────┼──┼──────────┼──────┤

@@ -417,8 +417,8 @@ This query means: "Drop the sname attribute from S filtered where status equals

417417The delete operator accepts a relation argument and a filtering predicate, creates a new relation with only the tuples which do not match the predicate, and stores the result in the relation variable argument.

418418

419419```

420−TutorialD (master): delete sp where s#="S4"

421−TutorialD (master): :showexpr sp

420+TutorialD (master/main): delete sp where s#="S4"

421+TutorialD (master/main): :showexpr sp

422422┌──┬───┬──┐

423423│p#│QTY│s#│

424424├──┼───┼──┤

@@ -437,7 +437,7 @@ TutorialD (master): :showexpr sp

437437This is logically equivalent to:

438438

439439```

440−TutorialD (master): sp:=sp where not s#="S4"

440+TutorialD (master/main): sp:=sp where not s#="S4"

441441```

442442

443443Note the inverted predicate.

@@ -453,7 +453,7 @@ Chris Date identified that all constraints can be represented as inclusion depen

453453Uniqueness constraints ensure that a set of attributes' values are unique throughout a relational expression. For example, it is useful to ensure that all products' identifiers are unique. The equivalent in SQL is the UNIQUE expression found in table creation.

454454

455455```

456−TutorialD (master): key s_key_constraint {s#} s

456+TutorialD (master/main): key s_key_constraint {s#} s

457457```

458458

459459This expression creates a constraint named "S_key_constraint" and ensure that the values of the "s#" attribute are unique in the "S" relational expression.

@@ -463,7 +463,7 @@ This expression creates a constraint named "S_key_constraint" and ensure that th

463463Foreign keys are constraints which require that certain values appearing in one relation variable must appear in another. The equivalent in SQL is the FOREIGN KEY() construction in table creation.

464464

465465```

466−TutorialD (master): foreign key s#_in_sp sp{s#} in s{s#}

466+TutorialD (master/main): foreign key s#_in_sp sp{s#} in s{s#}

467467```

468468

469469This expression ensure that any sp{s#} must also appear as a value in s{s#}.

@@ -475,7 +475,7 @@ Unlike SQL databases, Project:M36 includes first-class support for functional de

475475To create a functional dependency:

476476

477477```

478−TutorialD (master): funcdep sname_status (sname) -> (status) s

478+TutorialD (master/main): funcdep sname_status (sname) -> (status) s

479479```

480480

481481In this example, the functional dependency is named "sname_status" and creates a constraint which ensures that the "sname" value is functionally determines "status" value in the relation variable "s", though the final argument can be any relational expression. Multiple attribute names are separated by a comma.

@@ -485,7 +485,7 @@ In this example, the functional dependency is named "sname_status" and creates a

485485All other constraints can be represented by a set of inclusion dependencies.

486486

487487```

488−TutorialD (master): constraint s_status_less_than_50 (s where ^lt(50,@status)){} in false

488+TutorialD (master/main): constraint s_status_less_than_50 (s where ^lt(50,@status)){} in false

489489```

490490

491491This expression ensures that the relation variable's relation can never include a tuple with status greater than 50.

@@ -499,7 +499,7 @@ Aggregate queries in TutorialD are able to provide much more information than SQ

499499SQL supports aggregate queries using aggregate functions (SUM(), COUNT(), AVERAGE(), etc.) and GROUP BY while the aggregate functions in the relational algebra simply accept relation values as arguments.

500500

501501```

502−TutorialD (master): :showexpr s group ({s#,sname,status} as subrel):{citycount:=count(@subrel)}

502+TutorialD (master/main): :showexpr s group ({s#,sname,status} as subrel):{citycount:=count(@subrel)}

503503┌──────┬─────────┬─────────────────┐

504504│city │citycount│subrel │

505505├──────┼─────────┼─────────────────┤

docs/using_notifications.markdown+8−8

@@ -37,8 +37,8 @@ unnotify <notification name>

3737Consider the following ```person``` relation variable where "name" is a key:

3838

3939```

40−TutorialD (master): person:=relation{tuple{name "Steve",address "Main St."},tuple{name "John", address "Elm St."}}

41−TutorialD (master): :showexpr person

40+TutorialD (master/main): person:=relation{tuple{name "Steve",address "Main St."},tuple{name "John", address "Elm St."}}

41+TutorialD (master/main): :showexpr person

4242┌────────┬─────┐

4343│address │name │

4444├────────┼─────┤

@@ -50,22 +50,22 @@ TutorialD (master): :showexpr person

5050If a remote application is currently the address in the tuple for "Steve", then it would install a notification for that tuple's key:

5151

5252```

53−TutorialD (master): notify steve_change person where name="Steve" (person where name="Steve"){address}

54−TutorialD (master): :commit

53+TutorialD (master/main): notify steve_change person where name="Steve" (person where name="Steve"){address}

54+TutorialD (master/main): :commit

5555```

5656

5757Then, when any client including the initiating client updates the "Steve" tuple, an asynchronous notification is fired:

5858

5959```

60−TutorialD (master): update person where name="Steve" (address:="Grove St.")

61−TutorialD (master): :commit

62−TutorialD (master): Notification received "steve_change": ...

60+TutorialD (master/main): update person where name="Steve" (address:="Grove St.")

61+TutorialD (master/main): :commit

62+TutorialD (master/main): Notification received "steve_change": ...

6363```

6464

6565The asynchronously-received notification contains the result from the evaluated report relational expression. The expression, in this case, is the result of the report expression evaluated against the parent transactoin

6666

6767```

68−TutorialD (master): Notification received "steve_change":

68+TutorialD (master/main): Notification received "steve_change":

6969Project (AttributeNames (fromList ["address"])) (Restrict (AttributeEqualityPredicate "name" (NakedAtomExpr Atom "Steve")) (RelationVariable "person"))

7070┌────────┐

7171│address │