Howdah - An Application using Pylons, PostgreSQL, Simpycity and Exceptable
0 likes1,751 views
The document outlines a tutorial on designing and implementing a wiki, emphasizing the importance of treating databases as code. It covers steps for design, application development, API contracts, user permissions, and security considerations. The process is iterative, revisiting database and application needs as features expand and evolve.
Howdah - An Application using Pylons, PostgreSQL, Simpycity and Exceptable
- 1. HOWDAH A tutorial Tuesday, October 20, 2009
- 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
- 7. STEP 1: DESIGN 7 Tuesday, October 20, 2009
- 8. Database What do we need? 8 Tuesday, October 20, 2009
- 9. Application What do we need? 9 Tuesday, October 20, 2009
- 10. Application What do we need? Anything else? Did we miss anything? 10 Tuesday, October 20, 2009
- 11. STEP 2: REVISIT 11 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