Apologies again for not writing up more detailed meeting minutes.

Our sixteenth meeting was on Sept. 12, 2006 at Caltech in Pasadena.

Michael Carter gave us an overview of [http://www.sqlalchemy.org/ SQLAlchemy] (here are Michael's [http://socal-piggies.org/presentations/michael_carter/sqlalchemy/sa_slides.pdf slides in PDF format]), and he showed us code ([http://socal-piggies.org/presentations/michael_carter/sqlalchemy/examples_part1.py examples_part1.py] and [http://socal-piggies.org/presentations/michael_carter/sqlalchemy/examples_part2.py examples_part2.py]) that demonstrated some of the features he was presenting. Very cool indeed. Here is his speaking outline:

SA is an object relational mapper

What problem does an ORM solve?
    1. Persist data
    2. Data size > operating memory
    3. Share data between processes
    
What solves this problem
    1. Custom / Flat file storage
    2. Object Databases
    3. Relational Databases
    
How does a relational and object database differ?
    1. Tables vs. Serialized Objects
    2. Relational Algebra vs. Custom Indexes / Pointers
        What groups are Michael a member of?
            ODB: we have two pointers. Easy
            RDB: we have a table relating users to groups. select group_id from users_groups where user_id = michael
        What users are in Michael's network?        
            ODB: 
                users = []
                for group in michael.groups:
                    for user in group.users:
                        users.append = [ ]
            RDB: As with the previous problem, select the group_ids that relate to michael
                 Join first result on to middle table (users_groups) on group_id
                 Join second result back on to users on user_id
        Which of those two is faster?
            Asymptotically, the relational solution is signifigantly faster.
            On a more practical level, the hd access happens all at once in the RDB version
        
    3. So which is the best option thus far?
        ODB = matches our programming paradigm
              easier to think about
              very clear whats going on
              far more like python -- add del attributes to instances as desired.
        RDB = much faster to retrieve related data
    
Enter, SQLAlchemy
    1. Object Relational Mapper
    2. Takes best of two worlds
    3. Multiple levels of abstraction
        - SQL generation
        - database connection
        - data mappers
        - sessions
        
The Very Basics
    - Tables
        - Example
    - Queries
        - Raw SQL versus SA SQL
        - What groups is michael a member of?
    - Data Mapping
        1. Just a normal python object
            a. Unobtrusive
            b. Write a Constructor the same as always
            b. Serializeable
        2. Example
        
        3. Session
            - Objects must be in a session to interact with the db
            - Detachable (for serialization or moving to a different session)
            - Multiple active sessions (multiple concurrently active dbs)
            - Uni
        4. Unit of Work
            - Figures out the appropriate order of operations
                - Insert a new object, then insert many-many relations
                - Delete an object, then add another with the same uniquely indexed column-entry
                - 
            - Maintains new, dirty, clean, deleted

Steve Wedig talked about his PyJS project, whose goal is to turn Javascript into Python. He basically wrote the core Python language constructs in Javascript, to make life easier and more pythonic for those of us who have to write Javascript code. Very cool idea. Steve walked us through his code, which you can download as a [http://www.stevewedig.com/files/pyjs.zip zip file] from his Web site. Steve also started a [http://groups.google.com/group/pyjs PyJS Google Groups mailing list]. His next step is to rewrite the basic Python tutorial using PyJS. Can't wait to see this!

Many thanks to Michael and Steve for presenting, and to Titus and the other Caltech-ers for organizing the meeting.

Proposed agenda for next meeting:

SixteenthMeeting (last edited 2006-09-28 16:19:29 by ip68-5-227-59)