polish

Author: btholt

Diff for: lessons/01-welcome/A-intro.md

@@ -45,8 +45,6 @@ This course works and has been tested on both macOS and Windows 10/11. It also w
 
 I write these courses and take care to not make mistakes. However when teaching many hours of material, mistakes are inevitable, both here in the grammar and in the course with the material. However I (and the wonderful team at Frontend Masters) are constantly correcting the mistakes so that those of you that come later get the best product possible. If you find a mistake we'd love to fix it. The best way to do this is to [open a pull request or file an issue on the GitHub repo][issues]. While I'm always happy to chat and give advice on social media, I can't be tech support for everyone. And if you file it on GitHub, those who come later can Google the same answer you got.
 
-We'll talk about GitHub at the end of this class if that's unfamiliar to you.
-
 ## Who am I
 
 My name is Brian Holt and I am a product manager at Stripe. I work on all sorts of developer tools like the Stripe VS Code extension, the Stripe CLI, the Stripe SDKs, and other tools developers use to write code for Stripe. Before that I worked on Azure and VS Code at Microsoft as a PM and before that I was JavaScript (both frontend and Node.js) developer for a decade at companies like LinkedIn, Netflix, Reddit, and some other startups. I've written _a lot_ of code and written a lot of queries.

Diff for: lessons/02-databases-and-tables/B-tables.md

@@ -9,7 +9,7 @@ CREATE TABLE ingredients (
 
 > INT, INT4 or INTEGER are the same thing. Feel free to use what suits you. Similarly DEC, FIXED, and DECIMAL are the same thing.
 
-This will create our first table for us to start using. We will get into data types in the next lesson but know that it has a unique ID and a unique title.
+This will create our first table for us to start using. We will get into data types during the course but just know now that a VARCHAR is a string of max length 255 characters and an INTEGER is, well, an integer.
 
 To see the table you created, run `\d` in your psql instance to see it and the the sequence that you created. The sequence stores the `id` counter.
 

Diff for: lessons/03-data/A-inserts.md

@@ -18,12 +18,14 @@ Big key here which will throw JS developers for a loop: you _must_ use single qu
 
 ```sql
 INSERT INTO "ingredients" (
- "title", "image", "type"
+ "title", "image", "type" -- Notice the " here
 ) VALUES (
-  'broccoli', 'broccoli.jpg', 'vegetable'
+  'broccoli', 'broccoli.jpg', 'vegetable' -- and the ' here
 );
 ```
 
+> Use `--` for comments
+
 The above query works because the double quotes are around identifiers like the table name and the column names. The single quotes are around the literal values. The double quotes above are optional. The single quotes are not.
 
 Okay, let's insert a few more.

Diff for: lessons/03-data/C-selects.md

@@ -8,7 +8,7 @@ Let's next hop into SELECT, or how to read data from a database. We've already s
 SELECT * FROM ingredients;
 ```
 
-The _ there represents all available columns. Frequently, for a variety of reasons, we do not want to select everything. In general, I would recommend only using _ where your intent is truly "I want _anything this database could ever store for these records_". Frequently that is not the case. Frequently it is "I need the name, address and email for this email, but not their social security or credit card number". This is positive because it means smaller transfer loads, that your system only processes data it needs and not the rest, and it shows intention in your code.
+The \* there represents all available columns. Frequently, for a variety of reasons, we do not want to select everything. In general, I would recommend only using \* where your intent is truly "I want _anything this database could ever store for these records_". Frequently that is not the case. Frequently it is "I need the name, address and email for this email, but not their social security or credit card number". This is positive because it means smaller transfer loads, that your system only processes data it needs and not the rest, and it shows intention in your code. Honestly the biggest benefit is the latter: to show intentions in your code.
 
 So in our case we could put
 
@@ -25,8 +25,7 @@ Okay, now what if the user only wants five records?
 ```sql
 SELECT id, title, image
 FROM ingredients
-LIMIT 5
-OFFSET 5;
+LIMIT 5;
 ```
 
 This will limit your return to only five records, the first five it finds. You frequently will need to do this as well (as in almost always) since a database can contain _millions_ if not _billions_ of records.

Diff for: lessons/03-data/D-like-and-functions.md

@@ -15,7 +15,7 @@ This is a very limited fuzzy matching of text. This is not doing things like dro
 Okay, great, now what if a user searchs for "fruit"? We'd expect that work, right?
 
 ```sql
-SELECT * FROM ingredients WHERE concat(title, type) LIKE '%fruit%';
+SELECT * FROM ingredients WHERE CONCAT(title, type) LIKE '%fruit%';
 ```
 
 `concat()` is a function that will take two strings and combine them together. We can concat our two title and type columns and then used LIKE on the results on that combined string.
@@ -25,15 +25,15 @@ SELECT * FROM ingredients WHERE concat(title, type) LIKE '%fruit%';
 Okay, but what if we have capitalization problem? We can use lower, both on the columns and on the values.
 
 ```sql
-SELECT * FROM ingredients WHERE lower(concat(title, type)) LIKE lower('%FrUiT%');
+SELECT * FROM ingredients WHERE LOWER(CONCAT(title, type)) LIKE LOWER('%FrUiT%');
 ```
 
-`lower()` take a string and make it lowercase.
+`LOWER()` take a string and make it lowercase.
 
 Fortunately, there's an even easier way to do this with less function evocation.
 
 ```sql
-SELECT * FROM ingredients WHERE concat(title, type) ILIKE '%FrUiT%';
+SELECT * FROM ingredients WHERE CONCAT(title, type) ILIKE '%FrUiT%';
 ```
 
 `ILIKE` does the same thing, just with case insensitivity. Mostly I just wanted to show you lower!

Diff for: lessons/04-joins-and-constraints/D-many-to-many.md

@@ -9,14 +9,16 @@ This is a bit different because it's a many-to-many relationship. A recipe has m
 
 ```sql
 CREATE TABLE recipe_ingredients (
-  id INTEGER PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
   recipe_id INTEGER REFERENCES recipes(recipe_id) ON DELETE NO ACTION,
-  ingredient_id INTEGER REFERENCES ingredients(id) ON DELETE NO ACTION
+  ingredient_id INTEGER REFERENCES ingredients(id) ON DELETE NO ACTION,
+  CONSTRAINT recipe_ingredients_pk PRIMARY KEY (recipe_id, ingredient_id)
 );
 ```
 
 We set this to error because we should clear out connections before we let developers delete recipes or ingredients. We don't want to cascade deletes because that could delete recipes and ingredients unintentionally and we don't want to set to null because then we'd have a bunch of half-null connections left over.
 
+We're going over constraints in the next chapter but we're basically saying "the combination of recipe_id and ingredient_id must be unique" and we're setting that as the primary key instead of an incrementing ID.
+
 This table will describe the many-to-many relationship with two foreign keys between ingredients and recipes. Now we can insert records into here that describe how an ingredient belongs to a recipe.
 
 ```sql
@@ -38,7 +40,6 @@ So now we have two recipes that have ingredients, cookies and empanadas. Since w
 
 ```sql
 SELECT
-  ri.id AS connection_id,
   i.title AS ingredient_title,
   i.image AS ingredient_image,
   i.type AS ingredient_type

Diff for: lessons/04-joins-and-constraints/E-constraints.md

@@ -8,6 +8,8 @@ A constraint is just a constraint you put around a column. For example, NOT NULL
 
 UNIQUE is another constraint that dictates that this column must be unqiue amongst all other columns. Ever wonder how an app can tell you so quickly if an email or a user name is taken so quickly? They likely use a UNIQUE constraint on those two columns. They should. PRIMARY is another such constraint.
 
+We also added a constraint on recipe_ingredients that every row must have a unique combination of recipe_id and ingredient_id. We could have added an additional primary, incrementing, unique ID but what would we use that for? To me at this moment it doesn't serve a purpose so we can just use the other two as a unique key. This is common for these sorts of many-to-many connecting tables.
+
 Foreign keys are a type of constraint as well. They enforce consistency amongst tables.
 
 ## CHECK

Diff for: public/recipes.sql

@@ -20,9 +20,9 @@ CREATE TABLE recipes_photos (
   recipe_id INTEGER REFERENCES recipes(recipe_id) ON DELETE CASCADE
 );
 CREATE TABLE recipe_ingredients (
-  id INTEGER PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
   recipe_id INTEGER REFERENCES recipes(recipe_id) ON DELETE NO ACTION,
-  ingredient_id INTEGER REFERENCES ingredients(id) ON DELETE NO ACTION
+  ingredient_id INTEGER REFERENCES ingredients(id) ON DELETE NO ACTION,
+  CONSTRAINT recipe_ingredients_pk PRIMARY KEY (recipe_id, ingredient_id)
 );
 
 INSERT INTO

Diff for: styles/courses.css

@@ -258,6 +258,10 @@ header .cta-btn {
   line-height: 180%;
 }
 
+.lesson li li {
+  margin-left: 25px;
+}
+
 .lesson-links {
   font-size: 18px;
   padding: 15px 0;