2. Why?
Howdah is for people who really “get” databases
Howdah treats your database as code. Procedures,
and hand-written SQL.
Would you automate python generation? Then why
SQL?
Just because it’s not code you’re comfortable with,
doesn’t make it any less code.
2
Tuesday, October 20, 2009
3. What shall we build?
Today, we’ll be talking about designing and
implementing a Wiki.
3
Tuesday, October 20, 2009
4. Why a Wiki?
Canonical example
Simple enough to define in an afternoon
Complex enough to require in-depth exploration
4
Tuesday, October 20, 2009
5. Why a Wiki?
Public and Private permissions/users
Read/write collaborative model
5
Tuesday, October 20, 2009
6. Design vs. Code
Speaking more on Design than on Code
Why is more important than How.
How is still important
6
Tuesday, October 20, 2009
12. Database
Based on our Application design, what expansions do
we need?
12
Tuesday, October 20, 2009
13. Database
Based on our Application design, what expansions do
we need?
Why do we need them?
13
Tuesday, October 20, 2009
14. Application
With the new DB features, what changes?
14
Tuesday, October 20, 2009
15. Application
With the new DB features, what changes?
What new ideas are evident?
15
Tuesday, October 20, 2009
16. Application
With the new DB features, what changes?
What new ideas are evident?
Do the changes make things easier?
16
Tuesday, October 20, 2009
17. STEP 3:
API CONTRACTS
17
Tuesday, October 20, 2009
18. Database
Defining our API
What stored procedures do we need?
18
Tuesday, October 20, 2009
19. Database
Defining our API
What stored procedures do we need?
What should they do?
19
Tuesday, October 20, 2009
20. Database
Defining our API
What exceptions do we need?
20
Tuesday, October 20, 2009
21. Database
Defining our API
What exceptions do we need?
Null data
Bad data
No such record
21
Tuesday, October 20, 2009
22. Application
Defining our API
What models do we need?
22
Tuesday, October 20, 2009
23. Application
Defining our API
What exceptions do we need?
23
Tuesday, October 20, 2009
24. Application
Defining our API
What exceptions do we need?
What do DB exceptions become?
What HTTP responses should the exceptions
raise?
24
Tuesday, October 20, 2009
25. Application
Defining our API
What views do we need?
25
Tuesday, October 20, 2009
26. Application
Defining our API
What views do we need?
What views are read-only? Read-write? Write-only?
26
Tuesday, October 20, 2009
27. STEP 4:
FIRST EXPANSION
USERS
27
Tuesday, October 20, 2009
28. Database
Users
User system!
28
Tuesday, October 20, 2009
29. Database
Users
User system!
VerticallyChallenged for users
29
Tuesday, October 20, 2009
30. Database
Users
User system!
VerticallyChallenged for users
How to set up VC
30
Tuesday, October 20, 2009
31. Database
Users
Stored Procedures - How do we adapt them?
How does this affect our API contract?
31
Tuesday, October 20, 2009
32. Application
Users
Using @needs to define permissions
How should views be protected?
32
Tuesday, October 20, 2009
33. Application
Users
Using @needs to define permissions
How should views be protected?
Should anonymous users have write permission?
33
Tuesday, October 20, 2009
34. Application
Users
Permissions violations
What should no user return?
What should a bad user return?
What should insufficient permissions return?
34
Tuesday, October 20, 2009
35. Application
Users
Why - Are there better mechanisms?
35
Tuesday, October 20, 2009
36. STEP 5:
ADMINISTRATIVE
USERS
36
Tuesday, October 20, 2009
37. Database
Administrators
What delineates an admin?
What special things can an admin do?
Should admins be otherwise normal users?
37
Tuesday, October 20, 2009
38. Database
Administrators
Root-level permissions:
Should the database superuser ever be allowed to log
in from the web app?
38
Tuesday, October 20, 2009
39. Database
Administrators
Root-level permissions:
Should the database superuser ever be allowed to log
in from the web app?
Why?
39
Tuesday, October 20, 2009
40. Application
Administrators
What delineates an Admin?
40
Tuesday, October 20, 2009
41. Application
Administrators
Design
Are there special admin-only views?
How do we protect admin privileges?
Are there user-specific views? Do admins have
permission to access those?
Is anything changed by the DB layer?
41
Tuesday, October 20, 2009
42. Application
Administrators
Should administrators be able to view everything?
42
Tuesday, October 20, 2009
43. Application
Administrators
Should administrators be able to view everything?
What about privileged information?
HIPAA, lawyer confidentiality
43
Tuesday, October 20, 2009
44. Application
Administrators
Should administrators be able to view everything?
What about privileged information?
HIPAA, lawyer confidentiality
How can we protect privileged information like this?
Can we ever guarantee protection? How?
44
Tuesday, October 20, 2009
45. STEP 6:
A NEW FEATURE
45
Tuesday, October 20, 2009
46. A New Feature
Let’s add a user profile page
Specifically list the pages that a user has edited
46
Tuesday, October 20, 2009
47. Database
A New Feature
Design first!
47
Tuesday, October 20, 2009
48. Database
A New Feature
Design first!
Do we need new stored procedures?
What are they?
Who has access to them?
Does this require write access?
48
Tuesday, October 20, 2009
49. Application
A New Feature
What does the app need to support this?
49
Tuesday, October 20, 2009
50. Application
A New Feature
What does the app need to support this?
What views do we need?
50
Tuesday, October 20, 2009
51. Application
A New Feature
What does the app need to support this?
What views do we need?
Who has access to the views?
Logged-in users only?
51
Tuesday, October 20, 2009
52. Application
A New Feature
What about security and data confidentiality?
What security issues could be present?
52
Tuesday, October 20, 2009
53. Application
A New Feature
What about security and data confidentiality?
What security issues could be present?
Do we list entries that a user may not have read
access to?
53
Tuesday, October 20, 2009
54. Application
A New Feature
What about security and data confidentiality?
What security issues could be present?
Do we list entries that a user may not have read
access to?
Should we list nothing, instead?
Why do it like this? Are there better solutions?
54
Tuesday, October 20, 2009
