I like the general take. My first thoughts:
If db provided an appropriate __all__ then this would be more succinct:
from django.db import *
class Toy(Model):
name = CharField(maxlength=30)
colour = CharField(maxlength=30)
class Person(Model):
first_name = CharField(maxlength=30)
last_name = CharField(maxlength=30)
toy = ForeignKey(Toy)
And, as Hugo mentioned, ticket #980 makes querying nicer:
# construct query with AND
results = Person.select(field.first_name == 'Adrian', field.last_name
== 'Holovaty')
# extend query with OR
results += Person.select(field.toy.colour.startswith('r'))
# actually execute COUNT query on __len__
print len(results)
# or retrieval query on __iter__
for result in results:
print result
So then I took a look at the SQLObject docs
(http://www.sqlobject.org/SQLObject.html) and (take cover) this is
starting to look more and more like SQLObject :) If only SQLObject
didn't have such an unmarketable name. If Ian Bicking were better at
picking names then he'd probably be most of the way to world
domination. I digress.
I like that SQLObject has a debug mode in the interactive interpreter
that displays queries as they happen. I like that SQLObject lets you
add and remove fields at runtime.
On the other hand I like that Django ORM explicitly requires save().
It's more efficient and though lazy updates are now optional in
SQLObject, lazy creates still aren't and it's sometimes useful to
create non-persistent instances. I like that the rumour is that
performance is better in Django.
I like that the Django ORM works the Django way (whatever way that may
be). I don't like that brilliant people are wasting their time on
competing ventures when they would be much better wasting it on Django.
Kieran
