Errata for Data Crunching

#23190: The listing of the Regular Expressions search pattern contains an error - at least according to running the program on page 48 in python22 on windows. Here are my results:

'' a b Xab aXb abX ab aXXXb a.b
'' + + + + + + + + +
a - + - + + + + + +
a.b - - - - + - - - +
a?b - - + + + + + + +
a*b - - + + + + + + +
a+b - - - + - + + - -
a\.b - - - - - - - - +
a\+b - - - - - - - - -
.*ab - - - + - + + - -

The error is that obviously "a?b" matches "aXb" when searching, as it should match the same as "b" or "ab".

The error propagates down page 49 in the 3rd paragraph. The last sentence reads: "or aXb (the a and the b aren't adjacent)." Well, they're not and they don't have to be.

The following paragraph on the other hand is perfect even though the description clashes with the faulty table and the description just provided.

--Per Holst

#23457: To the best of my knowledge, the domain component of an email address has to contain two segments, e.g. a@b.c is OK but a@b isn't. Your RE matches a@b.

If I'm right, the correct RE is more like:

([\w.-]+@([\w-]+\.)+[\w-]+)(.*)

(That includes your group 3 for matching the rest of the line.)

Great book!--Dan Cooperstock

#25582: In the first paragraph that starts on the page, "/project/*/author" will match only authors of tickets. It will NOT match authors of comments. To match authors of comments, "/project/*/*/author" works. To match authors of both tickets and comments, use "/project//author."--Andy Fox

#22795: All implementations of Java in widespread use today will optimize repeated string concatenation, so that "abc"+"def"+"ghi" doesn't allocate an unnecessary intermediate buffer.--Matthew Wilson

#23221: The query "Find people in 904 or 905, but not both." is incorrect.

SELECT Person.FirstName, Person.LastName
FROM Person, Assigned
WHERE (Person.EmpId = Assigned.EmpId)
AND ((Assigned.ProjId = 904) OR (Assigned.ProjId = 905))
AND (Assigned.ProjId NOT IN
(SELECT A.ProjId
FROM Assigned A, Assigned B
WHERE (A.ProjId = 904) AND (B.ProjId = 905)));

is a clumsy way of saying: "People not assigned to project 904"

And the result is not the same as "Select people who are assigned to exactly one project" - which it should be, as stated in the text.

The correct query is:
-- Find people in 904 or 905, but not both.
SELECT Person.FirstName, Person.LastName
FROM Person, Assigned
WHERE (Person.EmpId = Assigned.EmpId)
AND ((Assigned.ProjId = 904) OR (Assigned.ProjId = 905))
AND (Person.EmpId NOT IN
(SELECT A.EmpId
FROM Assigned AS A, Assigned AS B
WHERE (A.ProjId = 904) AND (B.ProjId = 905) AND A.EmpId = B.EmpId));

The result is:
Dave|Thomas
Andy|Hunt
Grace|Hopper
Chuck|Babbage

which, of course, is not the result stated in the book.

--Per Holst

#23490: According to SQL standards, as I understand them, the statement near the bottom of the page that the condition CustId <> 1027 will match rows where CustId is NULL is wrong. Thus, the alternate query at the bottom of the page is not required. NULL does not compare to any value, using any comparison operator. Thus, NULL = 0, NULL <> 0, NULL < 0, and NULL > 0 all evaluate to false.--Dan Cooperstock