4 ms·

> I've made three sites in python/django, it works but the ORM is very limiting and I keep hearing that forms are hell (but I rolled my own forms, so that wasn'

by mattdw 17y ago

> I've made three sites in python/django, it works but the ORM is very limiting and I keep hearing that forms are hell (but I rolled my own forms, so that wasn't a big deal). Huh. That's not been my experience at all. I guess if you're trying to build full-strength webapps that might be the case, but we've built a decent number of fairly complex user-content-managed type sites, and Django has not caused any trouble at all. Very occasionally we step out of the ORM (usually in places we should be stepping out of RDMS in general, anyway, like tracking ad-clicks). (The ORM does now support aggregation, too - SUM(), AVG(), ad-hoc calculations etc.) And the Forms lib is great if you're happy with default html-generation (it can do paras or tables); things get kinda fiddly when you're trying to customise layout and appearance, but it's still nice having validation, saving to the db etc. all in one place.

jacquesm 17y ago
A complex query is one that hits several tables in several databases on more than one server. You can simply forget that using django, you'll have to export all the stuff you want to query in a format that exactly matches Djangos field name magic. And better not get any of that wrong or you'll be tearing your hair out, an underscore in the wrong spot and it will look just fine but it will never work and the error messages you'll get are much less than helpful. Here is a comment from the models.py file in one of my little django applications: # caveat, the related_name parameters of parent and thread # should not be parent_id or thread_id, this leads to # an 'add() argument after * must be a sequence' error # when transforming the template. Apparently the names # clash with the underlying field names that django # uses for these fields. So, effectively, what this is all about is that django names a bunch of fields in the queries as aliases, but does not check if there are real fields with those names.
- mattdw 17y ago
  Okay, I see. In that case, you're being tripped up by the fact that `parent = ForeignKey(OtherModel)` actually creates a database field `parent_id`; parent just becomes a synthetic property. AFAIK foreign keys and "_id" is the only place that happens. On the whole though, I think you're exaggerating the "field name magic". Double-underscores in field names would be a bigger problem, but python considers those special anyhow. And sure, cross-database and cross-server are weak points for Django. I guess it depends on the scale and complexity of what you're building… I build reasonably conventional websites for a living, and haven't hit too much pain with Django.
  - jacquesm 17y ago
    I've written a HN clone, both in PHP and another one in Django, they look and function exactly the same. The idea was that both could talk to the same database to check performance, and to get an idea about how much code was required in each to accomplish this. This would have worked if I had started from python/django, but writing the PHP part first and then the python part got me caught up a couple of times. Now for me it was no big deal to change the underlying field names, but if this would have been embedded in to something larger a restriction like that could even turn in to a dealbreaker. What's a minor nuisance to a lone programmer can be a very big issue in a corporate setting, where there might be lots of other software talking to that same db. In general I think it is a bad idea to resort to tricks like these. Indeed, the __ is another one, and the fact that you can't prefix field names with database names is another.
    - mattdw 17y ago
      (sorry, this is way old, but I just saw your response) you might be interested in the 'db_column' option to Django fields, e.g. content = models.TextField(db_column='a_different_column_name') That will allow you to have 'content' on the model, but 'a_different_column_name' in the database. It can be quite helpful for talking to legacy systems.

by mattdw 17y ago

jacquesm 17y ago

A complex query is one that hits several tables in several databases on more than one server. You can simply forget that using django, you'll have to export all the stuff you want to query in a format that exactly matches Djangos field name magic. And better not get any of that wrong or you'll be tearing your hair out, an underscore in the wrong spot and it will look just fine but it will never work and the error messages you'll get are much less than helpful. Here is a comment from the models.py file in one of my little django applications: # caveat, the related_name parameters of parent and thread # should not be parent_id or thread_id, this leads to # an 'add() argument after * must be a sequence' error # when transforming the template. Apparently the names # clash with the underlying field names that django # uses for these fields. So, effectively, what this is all about is that django names a bunch of fields in the queries as aliases, but does not check if there are real fields with those names.

mattdw 17y ago
Okay, I see. In that case, you're being tripped up by the fact that `parent = ForeignKey(OtherModel)` actually creates a database field `parent_id`; parent just becomes a synthetic property. AFAIK foreign keys and "_id" is the only place that happens. On the whole though, I think you're exaggerating the "field name magic". Double-underscores in field names would be a bigger problem, but python considers those special anyhow. And sure, cross-database and cross-server are weak points for Django. I guess it depends on the scale and complexity of what you're building… I build reasonably conventional websites for a living, and haven't hit too much pain with Django.
- jacquesm 17y ago
  I've written a HN clone, both in PHP and another one in Django, they look and function exactly the same. The idea was that both could talk to the same database to check performance, and to get an idea about how much code was required in each to accomplish this. This would have worked if I had started from python/django, but writing the PHP part first and then the python part got me caught up a couple of times. Now for me it was no big deal to change the underlying field names, but if this would have been embedded in to something larger a restriction like that could even turn in to a dealbreaker. What's a minor nuisance to a lone programmer can be a very big issue in a corporate setting, where there might be lots of other software talking to that same db. In general I think it is a bad idea to resort to tricks like these. Indeed, the __ is another one, and the fact that you can't prefix field names with database names is another.
  - mattdw 17y ago
    (sorry, this is way old, but I just saw your response) you might be interested in the 'db_column' option to Django fields, e.g. content = models.TextField(db_column='a_different_column_name') That will allow you to have 'content' on the model, but 'a_different_column_name' in the database. It can be quite helpful for talking to legacy systems.