I have read the Django docs on adding custom SQL commands to an app's sql subfolder, so that is what I'm going to do. I'm not yet using South, but I will review it if I start. I agree item #2 seems the hardest problem.
On testing, I have found that the Django test runner executes my custom SQL when it creates/syncs the test database, so I'm all good there. It's too bad that the custom SQL is necessary. On the other hand, it also lets me set up CHECK constraints. I wish that this project: http://code.google.com/p/django-check-constraints/ had made it into Django. Here's an example of my custom SQL: >From file job_sites/sql/site.postgis.sql: -- Defaults ALTER TABLE sites ALTER COLUMN date_entered SET DEFAULT now(); -- Constraints ALTER TABLE sites ADD CONSTRAINT sites_site_name_minlen CHECK (char_length(site_name) > 0); On Friday, January 11, 2013 7:01:40 AM UTC-5, akaariai wrote: > > On 10 tammi, 16:04, john.wolt...@tpiengineering.com wrote: > > What is the best way to specify a database level default value with > > Django? If I want a timestamp column to default to the SQL function > now(), > > is there an accepted way to make it happen? Or to default a boolean > column > > to True? I notice that when I call *manage.py sqlall* I don't see any * > > DEFAULT* values specified in the generated queries for Postgres. > > Support for this would be an useful addition. Personally I have need > for at least now() and txid_current(), but preferably we want any > default clause (maybe even any per column SQL, so that you could do > CHECK too). > > There are three problems for this feature: > 1. How to get the SQL into the CREATE TABLE clauses? > 2. How to return the values back after insert? > 3. If the way for no.1 is hand edited SQL, how to support this in > testing? > > Above, no.2 seems the hardest problem. Some databases support > RETURNING, but not all. > > Currently, you can do DB defaults by hand editing the sqlall output + > using post_save signal() and fetch the DB generated values into the > saved instance in the signal. But, you will need some way to solve no. > 3 in this case. South might be a good option here. Personally I use a > custom testing system where I load the database schema from production > (with some data, too), apply migrations (that is, load custom SQL) and > then run tests. > > - Anssi > -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/jytjZezBHsUJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
