3 ms·

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

by 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

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.