Re: Modify .save() implementation
On 13 joulu, 22:11, Emil Stenström wrote: > I just thinking out loud here but: what if another thread does something to > the previously loaded object? I'm not sure if Django has concurrency tests > build into the test suite, but if it hasn't it could explain why the code > is written as it is. I have added tests for concurrent delete + save. I have also updated the patch in other respects. Some polish done, and docs added. The patch can be found from https://github.com/akaariai/django/compare/model_save_refactor. It should be commit-ready. I hope somebody has time to check the altered .save() coding - the save_base is split into save_base, _save_parents, _save_table, _do_update and _do_insert. This splitting isn't necessary for the UPDATE, if not updated, INSERT behavior, but it cleans up the code, and it also allows for some nice things when combined with customizable model ._state. See ticket https://code.djangoproject.com/ticket/19396 for the model._state part. The custom _state classes allow for tracking model's dirty fields and updating automatically only those, true updatable primary keys and optimistic locking. The two first are implemented in tests for the ticket, see https://github.com/akaariai/django/compare/model_state_improvements#L6R0. The patch isn't yet rebased onto latest revision of model_save_refactor. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: Django URL Admin (django-urls)
Yeah, I agree, as it is, I can't see any reason why I would use it, but I could see it being useful with some modifications such as: 1) Being able to create redirects (which seems to already be on the todo-list) 2) Being able to specify extra kwargs to pass to a view so that it would be possible to change the functionality of a view without adding a new model to store the different options (or have to change the urlconfig and push new code every time). Until those things are implemented (which allow for things that could probably be implemented in more straightforward/non-dev-user friendly ways), it seems like a bad idea to store infrastructure in the database (I can only see it causing problems when you have developers working from a different urlconf than the production server is using). On Friday, December 14, 2012 11:31:34 PM UTC-6, Amirouche B. wrote: > > > > On Friday, December 7, 2012 9:07:32 PM UTC+1, Zach Borboa wrote: >> >> Does something like this exist already? If not, it should. > > > How this can be useful ? You still need to write the view in Python then > why not write the urls in Python too, like it's currently the way to go. > > If something in this spirit might be useful is something where the view > could be generated which would be something like databrowser or admin. > > Could you elaborate ? > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/GSfX8xoF550J. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Where is the authentication backend used?
Hello everyone I've tried getting my question answered by the folks over django-users but when searching the archives I didn't feel that I would get a sufficient response there. On my current project I need a mix of builtin Django authentication and oAuth2 sources. But when writing a custom authentication backend, when does it get used? The docs say: """Once a user has authenticated, Django stores which backend was used to authenticate the user in the user's session, and re-uses the same backend for the duration of that session whenever access to the currently authenticated user is needed.""" The code of ModelBackend only seems to deal with permissions. Assuming an oAuth2 source deals with authentication my backend should only handle permission checks? Thanks for taking the time to answer this. Kind regards Michael -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/UeWpZ7m5kQYJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.1 is not installable
On Saturday, December 15, 2012 3:54:10 AM UTC-8, Florian Apolloner wrote: > > I am strongly against showing non-supported versions on PYPI, I also don't > see why you'd need 1.1 for CI tests if you don't use it (an nobody should) > I disagree. I have a client who is currently running a site with Django 1.0 and a correspondingly old version of Satchmo. In the next few months I intend to upgrade them to at least 1.4 of Django and a compatible version of Satchmo. To do that, I am going to upgrade in steps on the test server, 1.1, 1.2, 1.3, 1.4, testing and rewriting deprecated APIs as I go. Sure, I have a copy of the repository and can check out tagged versions as I need them, but having specific versions listed in my requirements file makes pip installs much more convenient. 1.1 may not be supported by the Django project team, but developers out here still have to. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/VgcZ48SXW1QJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: Django URL Admin (django-urls)
> 1) Being able to create redirects (which seems to already be on the > todo-list) Creating temporary 302 redirects are currently possibly right now. The TODO is for being able to specify both 301 and 302 redirects through the admin. > 2) Being able to specify extra kwargs to pass to a view so that it would be > possible to change the functionality of a view without adding a new model to > store the different options (or have to change the urlconfig and push new > code every time). You can still specify additional urls in urls.py as the framework allows you to do normally; django-urls simply appends to that list of urls. There is also a TODO for adding the ability to edit views through the Django admin using the same editor GitHub uses. These should cover the use cases you describe. On Sat, Dec 15, 2012 at 11:52 PM, Sam Solomon wrote: > Yeah, I agree, as it is, I can't see any reason why I would use it, but I > could see it being useful with some modifications such as: > > 1) Being able to create redirects (which seems to already be on the > todo-list) > 2) Being able to specify extra kwargs to pass to a view so that it would be > possible to change the functionality of a view without adding a new model to > store the different options (or have to change the urlconfig and push new > code every time). > > Until those things are implemented (which allow for things that could > probably be implemented in more straightforward/non-dev-user friendly ways), > it seems like a bad idea to store infrastructure in the database (I can only > see it causing problems when you have developers working from a different > urlconf than the production server is using). > > > On Friday, December 14, 2012 11:31:34 PM UTC-6, Amirouche B. wrote: >> >> >> >> On Friday, December 7, 2012 9:07:32 PM UTC+1, Zach Borboa wrote: >>> >>> Does something like this exist already? If not, it should. >> >> >> How this can be useful ? You still need to write the view in Python then >> why not write the urls in Python too, like it's currently the way to go. >> >> If something in this spirit might be useful is something where the view >> could be generated which would be something like databrowser or admin. >> >> Could you elaborate ? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: Django URL Admin (django-urls)
Since this isn't really appropriate for django-dev, could we move any further discussion on this over to the django-users group, please? Many thanks! Tom On Sunday, 16 December 2012 18:53:43 UTC, Zach Borboa wrote: > > > 1) Being able to create redirects (which seems to already be on the > > todo-list) > > Creating temporary 302 redirects are currently possibly right now. The > TODO is for being able to specify both 301 and 302 redirects through > the admin. > > > > 2) Being able to specify extra kwargs to pass to a view so that it would > be > > possible to change the functionality of a view without adding a new > model to > > store the different options (or have to change the urlconfig and push > new > > code every time). > > You can still specify additional urls in urls.py as the framework > allows you to do normally; django-urls simply appends to that list of > urls. There is also a TODO for adding the ability to edit views > through the Django admin using the same editor GitHub uses. These > should cover the use cases you describe. > > > On Sat, Dec 15, 2012 at 11:52 PM, Sam Solomon > > wrote: > > Yeah, I agree, as it is, I can't see any reason why I would use it, but > I > > could see it being useful with some modifications such as: > > > > 1) Being able to create redirects (which seems to already be on the > > todo-list) > > 2) Being able to specify extra kwargs to pass to a view so that it would > be > > possible to change the functionality of a view without adding a new > model to > > store the different options (or have to change the urlconfig and push > new > > code every time). > > > > Until those things are implemented (which allow for things that could > > probably be implemented in more straightforward/non-dev-user friendly > ways), > > it seems like a bad idea to store infrastructure in the database (I can > only > > see it causing problems when you have developers working from a > different > > urlconf than the production server is using). > > > > > > On Friday, December 14, 2012 11:31:34 PM UTC-6, Amirouche B. wrote: > >> > >> > >> > >> On Friday, December 7, 2012 9:07:32 PM UTC+1, Zach Borboa wrote: > >>> > >>> Does something like this exist already? If not, it should. > >> > >> > >> How this can be useful ? You still need to write the view in Python > then > >> why not write the urls in Python too, like it's currently the way to > go. > >> > >> If something in this spirit might be useful is something where the view > >> could be generated which would be something like databrowser or admin. > >> > >> Could you elaborate ? > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/G1CLGO-hWpQJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
SVG images in docs
Hello, Since all major browsers now support SVG [1], I've replaced two images in the docs with SVG versions [2] [3]. This isn't a new idea [4]. [1] http://caniuse.com/#feat=svg [2] https://docs.djangoproject.com/en/dev/topics/http/middleware/#hooks-and-application-order [3] https://docs.djangoproject.com/en/dev/topics/testing/#test-cases [4] https://code.djangoproject.com/ticket/15516#comment:7 Since they're resolution independent, they look much better at non-native resolutions — eg. on Retina displays, or when the page is zoomed in or out. The downside is that IE <= 8 and Android <= 2.x can't display these images. I don't believe many developers read Django's docs on these browsers, but let me know if that's a real inconvenience. I had to include a PDF version too (thanks Tim for noticing) because Sphinx' PDF builder doesn't support SVG. The following syntax tells Sphinx to look for the most appropriate format among those available: .. figure:: _images/myimage.* If _images contains myimage.pdf and myimage.svg, the HTML builder will then use myimage.svg and the PDF builder myimage.pdf. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Where is the authentication backend used?
On Sunday, December 16, 2012 12:39:13 AM UTC-8, Michael Anckaert wrote: > > Hello everyone > > I've tried getting my question answered by the folks over django-users but > when searching the archives I didn't feel that I would get a sufficient > response there. > This list is not the place to attempt second tier support requests, it is limited to the development of Django itself. Even custom auth backends are a use of Django, not development of Django, albeit advanced. This topic is in fact covered in the docs https://docs.djangoproject.com/en/dev/topics/auth/#specifying-authentication-backends -Preston -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/s9wJYoUyiuEJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.1 is not installable
The point is that you should be using 1.1.4, the latest release in the 1.1 line, and not 1.1. Jacob On Sun, Dec 16, 2012 at 12:38 PM, donarb wrote: > > > On Saturday, December 15, 2012 3:54:10 AM UTC-8, Florian Apolloner wrote: >> >> I am strongly against showing non-supported versions on PYPI, I also >> don't see why you'd need 1.1 for CI tests if you don't use it (an nobody >> should) >> > > I disagree. I have a client who is currently running a site with Django > 1.0 and a correspondingly old version of Satchmo. In the next few months I > intend to upgrade them to at least 1.4 of Django and a compatible version > of Satchmo. To do that, I am going to upgrade in steps on the test server, > 1.1, 1.2, 1.3, 1.4, testing and rewriting deprecated APIs as I go. > > Sure, I have a copy of the repository and can check out tagged versions as > I need them, but having specific versions listed in my requirements file > makes pip installs much more convenient. > > 1.1 may not be supported by the Django project team, but developers out > here still have to. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/VgcZ48SXW1QJ. > > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
