I just committed change number 290 to the TurboGears subversion repository and it breaks everything!
Well, not really, but it will break every existing system using the default Identity provider (SqlObjectProvider). The reason for this change is that I misread the SQLObject documentation on joins — which is pretty easy to do because they don’t make any sense to me. I had mistaken joinColumn for otherColumn.
It’s so tempting to question the decisions of those who went before you when you’re getting to know a new programming environment. There are numerous things about Python that I’m not comfortable with yet (like line continuation, why not just indent a bit more to indicate a continuation?) but overall I think it’s cool.
I’ve just checked in revision 255 which contains modifications to the Identity framework.
Recently there’s been some discussion on the TurboGears mailing list about how to get around a flaw in SQLObject where the classes from the SQLObjectProvider model are causing conflicts with existing model classes sharing the same names.
It’s also become clear that many people want to extend the default model to include additional fields and capabilities.
So it makes sense to provide a short tutorial on how to create an alternate model for the SQLObjectProvider. But first, I need to explain how the Filter processes each incoming request.
An important part of any ORM is being able to easily query the objects contained in the database. Not every ORM handles this particularly gracefully.
Probably the most graceful I’ve seen is the Pythonic query in Dejavu where you literally write Python code which gets disassembled and turned into queries under the covers.
One of the least graceful is the SQLBuilder module which is part of SQLObject. While I recognise the vast amount of really clever code that goes into making SQLBuilder work, I just find it icky. Note: This is just my personal opinion. Read Querying the Context »