pyodbc: Works in Plain Python, Django 1.8 Shell Throws Error
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 pyodbc, however, I get this: http://pastebin.com/cNDrmvcb Got a bit of help in IRC with someone suggested to turn on pdb trace on the run_shell command, which I did, but then I just get this: *** SystemError: initialization of pyodbc raised unreported exception I just can't figure out why it'd work in a plain python interpreter but not in the Django shell, and I'm not sure how to diagnose or troubleshoot further. Appreciate any tips or suggestions anyone might have. Thanks! -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/949d8be7-8ca2-499d-90eb-aa621498b038%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: "The outermost 'atomic' block cannot use savepoint = False when autocommit is off." error after upgrading to Django 1.8
Thanks so much for the quick and thorough reply! I think I'm set now with the "Right" example below -- I was getting errors (the most cryptic of which was just "__exit__") when I was trying various incarnations of atomic but it seems to be working now using the example you provided. The last thing I need to verify is the behavior change around assigning unsaved objects to relations since in this particular case I'm creating a new object and then saving other objects that have the first one as a FK, but that's looking good thus far in testing. Thanks again for your help -- much appreciated! Matt On Thursday, April 2, 2015 at 12:09:59 PM UTC-7, Simon Charette wrote: > > Hi Matt, > > I think it would be preferable to use atomic() here. > > From reading the documentation > <https://docs.djangoproject.com/en/1.8/topics/db/transactions/> it looks > like you might already be in a transaction when calling `set_autocommit` > but it's hard to tell without the full traceback. > > What kind of errors do you get from: > > def foo(request): > with transaction.atomic(): > # ... do stuff involving multiple database actions ... > > Note that you should never catch `DatabaseError` within an `atomic()` > context. You should wrap the context managed block with a try/except > instead: > > *Wrong* > with transaction.atomic(): > try: > # 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 > > Le jeudi 2 avril 2015 14:42:26 UTC-4, Matt Woodward a écrit : >> >> 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) >> >> ... do stuff involving multiple database actions ... >> except (DatabaseError, Exception) as e: >> transaction.rollback() >> >> This worked fine in 1.7.7 so I'm not sure what I need to change to get it >> working with 1.8. >> >> I did read the docs on the atomic() functionality and took a few runs at >> that but just wound up with different errors, so I thought I'd start with >> what I originally had and see what I need to change to make Django 1.8 >> happy. But if using the atomic() stuff is preferable any tips around that >> would also be appreciated; I can post the errors I'm getting when trying >> things that way as needed. >> >> Appreciate any ideas anyone has. Thanks. >> > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/02966744-31f5-496b-8f44-fcb551b4184c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
"The outermost 'atomic' block cannot use savepoint = False when autocommit is off." error after upgrading to Django 1.8
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) ... do stuff involving multiple database actions ... except (DatabaseError, Exception) as e: transaction.rollback() This worked fine in 1.7.7 so I'm not sure what I need to change to get it working with 1.8. I did read the docs on the atomic() functionality and took a few runs at that but just wound up with different errors, so I thought I'd start with what I originally had and see what I need to change to make Django 1.8 happy. But if using the atomic() stuff is preferable any tips around that would also be appreciated; I can post the errors I'm getting when trying things that way as needed. Appreciate any ideas anyone has. Thanks. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/670a0358-3538-4a2f-b5e3-b1c2a33076ee%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Django problem:AttributeError:Manage isn't accessible via Link instances
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 subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Question on Multiple Database Connections
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 directly with pyodbc, opening and closing the connection myself, and oddly enough the behavior is the same. Thanks for the idea though! I'll keep digging and report back if I figure anything out. I have some alternative ways to handle this situation anyway but I'm curious to get to the bottom of the behavior for my own knowledge if nothing else. -- 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/-/RKwMjfVjs7QJ. 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.
Re: Easy way to make all form fields read only?
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! :-) Really appreciate all the suggestions and tips I'm getting so far. -- 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/-/-yXv4JUztrsJ. 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.
Re: Easy way to make all form fields read only?
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 ModelForm using Layout() and Field() and it works a > treat. > Awesome -- thanks for the recommendation. I'll check it out. -- 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/-/C9yrVoM4OzUJ. 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.
Re: Easy way to make all form fields read only?
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 applies a different style via the CSS) but that's a really interesting additional piece to potentially throw into the mix. -- 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/-/zd40PUCUmwoJ. 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.
Re: Easy way to make all form fields read only?
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 elaborated a bit more to say what I'm looking for (that may not exist) is a way of not having to do a user check on every single field and set the readonly flag individually, particularly since (at least based on my knowledge thus far) that gets messy given that we're using ModelForm and trying to render the fields with a simple template tag as much as possible. I haven't looked into whether or not that could be conditionally added as an attribute in the ModelForm, but that was another thought that crossed my mind. > > However, we warned - if *some* of your users can edit and submit the > form, you should also introduce server-side check testing if user is > allowed to edit fields. Making form fields read only won't prevent > anyone from actually submitting changed data (as it's just a > client-side control which can be easily worked around) > Right, definitely will be doing this as well. Mostly the readonly state on the form is a visual/styling thing and also simply so there's no perception that people can edit things when they can't. Very good point to bring up though, and we'll definitely be checking again on the server side since as others have pointed out people can manipulate the DOM if they really want to wreak havoc. Thankfully this is an internal app which mitigates some of the danger, and certainly if this was a public app I would have fought a lot harder to not have a non-editable form be the way people view records. Thanks! -- 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/-/KicUDqaZrwYJ. 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.
Re: Easy way to make all form fields read only?
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 against Active Directory and we didn't yet look into tying that contrib.auth.user. Probably will do that on another phase of this app on Django 1.5 since that'll be a bit more flexible for our needs. Thanks. -- 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/-/I3YPr_VrXjMJ. 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.
Re: Newbie Project Setup and Terminology Questions
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 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.
