On Friday, March 7, 2014 2:58:29 AM UTC-5, Anssi Kääriäinen wrote:
>
> On Friday, March 7, 2014 12:11:59 AM UTC+2, Justin Michalicek wrote:
>>
>> It appears that due to test cases running in an atomic block, testing
>> methods which use transaction.set_autocommit() all
It appears that due to test cases running in an atomic block, testing
methods which use transaction.set_autocommit() all fail. I've got a small
handful of test cases around methods which need to use manual transaction
management and they are definitely working when I actually use the site,
but
It's pretty straightforward to get django to automatically upload
everything to s3 using https://github.com/qnub/django-boto/
I've only used it to server directly from s3, but it sounds like you might
want to upload to s3 and then serve from cloudfront. cloudfront uses edge
servers to serve con
I install it on my Mac running 10.8.4 using pip on a pretty regular basis
for starting new projects and testing things. I use postgres from
homebrew, virtualenv and virtualenvwrapper installed as system packages,
then install django as needed into virtualenvs using pip.
On Friday, August 2, 20
I would go with the Django ORM and just add a unique_together for a
multiple column uniqueness constraint. That index won't be your primary
key, but it will still be a unique index. I've even gone as far as to use
custom .sql files (which manage.py syncdb runs) and custom sql in South
migrati
It looks like maybe a slight change to your models and schema would make
this a bit cleaner if I'm understanding your overall schema correctly. I
would split this up into two different models with a ManyToMany
relationship in there. I am assuming you have students and then an Egitim
instance
6 matches
Mail list logo