On Tue, 22 Apr 2008 09:47:54 +0100, Robert Forkel
> On Tue, Apr 22, 2008 at 10:26 AM, Nick Murdoch <nmurdoch@...>
>> The difference to me is that SQLAlchemy requires you to know how SQL
>> in much greater depth, /and/ to learn how SQLAlchemy interfaces with it
>> all, before you can start using it. I'm not a DB expert, and I like how
>> SQLObject doesn't bother me with a lot of the details before getting on
>> with it.
> i think this also holds the other way round. if you already know how
> sql works, you might be better off with sqlalchemy. in my case, i
> already had a legacy db with composite, non-integer foreign keys, and
> changing the schema to make it work with sqlobject didn't really
> appeal to me.
Oh, definately. One of my colleagues prefers SA for exactly that reason.
Being able to fine-tune to that level certainly appeals to people, and as
you say, if you have an existing schema, there's not much you can do about
I'd certainly be interested in working on SO, if I had any free time at
the moment. I think having a roadmap or a ticketing system might be useful
for people though, since it'd mean people would be able to browse through
what needs/wants to be done next, and pick a favourite, rather than having
to come up with an idea for a feature themselves.