Running into a bit of an odd problem I hope someone can help with.
Envrionment:
* Ubuntu Server 14.04, 64-bit (Vagrant box)
* Python 3.4
* Django 1.8
* pyodbc 3.0.8
pyodbc installs fine. When I do python3 and then import pyodbc, that works
fine.
When I do python3 manage.py shell and then import
# Do database stuff possibly raising database errors
> except DatabaseError:
> pass
>
>
> *Right*
> try:
> with transaction.atomic():
> # Do database stuff possibly raising database errors
> except DatabaseError:
> pass
>
> Simon
>
Hi all -- I just upgraded one of my projects to Django 1.8 from 1.7.7 and
in a view function where we're doing manual transaction management
(Postgres) I'm now getting the error in the subject line.
Basic gist of the code involved:
def foo(request):
try:
transaction.set_autocommit(False)
On Thursday, March 21, 2013 12:49:45 AM UTC-7, simon xue wrote:
>
> When I read to page 31,"To get an object by ID,type the following:
> >>>Link.object.get(id=1)
Unless this is just a typo that should be objects plural:
Link.objects.get(id=1)
--
You received this message because you are sub
On Thursday, December 13, 2012 8:01:13 AM UTC-8, ke1g wrote:
>
>
> Just a shot in the dark: Maybe if, since you're not using the ORM on the
> 'other' database, you shouldn't use django-pyodbc, but rather just pyobdc.
>
I should have said this earlier but I had the same thought and tried doing
it
On Thursday, November 1, 2012 4:33:47 AM UTC-7, Amyth wrote:
> I would suggest you adding Boolean field to your UserProfile model like
> is_authorized = models.BooleanField(default=False)
Cool -- thanks for the suggestion. As I've said I'm new to the Django world
but this community rocks! :-)
On Wednesday, October 31, 2012 8:40:10 PM UTC-7, elena wrote:
> I was also going to suggest using crispy forms -- having used it on a
> recent project I'd strongly recommend it (it's great when it's plugged in
> to existing stylings such as: uni-form or bootstrap).
>
> I've used it with ModelFo
On Tuesday, October 30, 2012 5:20:44 AM UTC-7, ke1g wrote:
> Another protective hack would be to omit the
> CSRF token when the form is read only.
>
Thanks -- interesting idea! Ultimate goal is for the user to be able to
tell they can't edit the form via the fields being read only (which appli
On Tuesday, October 30, 2012 7:09:05 AM UTC-7, JirkaV wrote:
> On the UI side, you can set the "readonly" property on form fields.
> This will prevent the field from being edited in a browser (I think so
> - done that only once on a small internal project).
>
Thanks -- I probably should have e
On Tuesday, October 30, 2012 1:36:19 AM UTC-7, elena wrote:
> How are you rendering the form? Are you using `forms.Form`?
>
We're using a ModelForm specifically.
>
> Do you mean "user's credentials" from `django.contrib.auth`?
>
Actually this is a custom user object -- users authenticate agai
Thanks to all for the examples and insight! Very helpful.
Matt
--
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/-/sITNuGB_k54J.
To post to this group, send em
11 matches
Mail list logo
