3 ms·

SQLAlchemy is a great ORM, but I don't think I would say that it's phenomenally better than Django's (at least from a code perspective). Making an ORM have goo

by j_baker 17y ago

SQLAlchemy is a great ORM, but I don't think I would say that it's phenomenally better than Django's (at least from a code perspective). Making an ORM have good code is really hard, especially when you support as many databases as SQLAlchemy does. Not only does each database have its own quirks, but their drivers also have their own quirks, and so do the drivers' Python interfaces. And I haven't even gotten into the mess that is dealing with Unicode in Python 2. Long story short, show me a Python ORM that has clean code, and I'll show you an ORM that either supports just one database or is so buggy as to be unusable.

obeattie 17y ago
I do think you should at least take a look at SQLAlchemy's code before saying it isn't clean. I can tell you that SA's code is exceptionally clean and easy-to-follow (so long as you're comfortable with the 'a-class-for-everything' way of working, which is what makes sense in their case). As for messy code in Django, well that really isn't that fair. Sure, some of the things they do with imports is, frankly, scary, but there are very few cases where this becomes a problem, and when it does, there is always a workaround. Where, in my opinion, Django's ORM falls short is it doesn't really like you to think you're interacting with a database… many things that would be very useful just aren't there (swapping out ORM-generated SQL with a hand-written counterpart, for instance, is next to impossible). The typical solution to this seems to be "well, you can get a database cursor and do as you please"… but there comes a point where this just isn't good enough. However, if Django's ORM just can't cut it for you on a project for whatever reason, it really isn't that hard to ditch and switch to something else (like SA). Yes, you will lose the admin, and you'll lose the authentication and session components (though these are actually easier than one might assume to get working under another ORM with their 'backends' concept), but you still have an amazing framework without these components. Reading this article seems, to me, like the guy has taken one brief look at Django's internals before going on to condemn them as ugly in this post. And that's really not cool.
- j_baker 17y ago
  I have looked at SQLAlchemy's code, and I think it's about as clean as can be expected for an ORM. I wasn't trying to put SQLAlchemy down. I'm just saying that you have to apply a bit lower standard for ORM code than you would other parts of the code.

by j_baker 17y ago

obeattie 17y ago

I do think you should at least take a look at SQLAlchemy's code before saying it isn't clean. I can tell you that SA's code is exceptionally clean and easy-to-follow (so long as you're comfortable with the 'a-class-for-everything' way of working, which is what makes sense in their case). As for messy code in Django, well that really isn't that fair. Sure, some of the things they do with imports is, frankly, scary, but there are very few cases where this becomes a problem, and when it does, there is always a workaround. Where, in my opinion, Django's ORM falls short is it doesn't really like you to think you're interacting with a database… many things that would be very useful just aren't there (swapping out ORM-generated SQL with a hand-written counterpart, for instance, is next to impossible). The typical solution to this seems to be "well, you can get a database cursor and do as you please"… but there comes a point where this just isn't good enough. However, if Django's ORM just can't cut it for you on a project for whatever reason, it really isn't that hard to ditch and switch to something else (like SA). Yes, you will lose the admin, and you'll lose the authentication and session components (though these are actually easier than one might assume to get working under another ORM with their 'backends' concept), but you still have an amazing framework without these components. Reading this article seems, to me, like the guy has taken one brief look at Django's internals before going on to condemn them as ugly in this post. And that's really not cool.

j_baker 17y ago
I have looked at SQLAlchemy's code, and I think it's about as clean as can be expected for an ORM. I wasn't trying to put SQLAlchemy down. I'm just saying that you have to apply a bit lower standard for ORM code than you would other parts of the code.