Re: deadlock risk from using cache a load time
> Le 27 janv. 2016 à 00:59, Tim Graham a écrit : > > Regarding the original issue -- in Claude's use case, he says that calling > django.setup() before unpickling is not doable, as an external tool is doing > the unpickling of model data. Should we say that unpickling model data from > non-Django code is no longer possible? There's an inconsistency that bothers me in this case with the current implementation (unless I missed something — I didn't try it). If the task's arguments include at least one model instance, this will implicitly trigger django.setup() and the code can use the ORM (and logging is set up correctly, etc.) If the code is refactored to pass the instance id in argument and the task function attempts to load the corresponding instance from the database, it will raise an exception when attempting to import the model. This inconsistency sounds surprising and hard to diagnose. I'm not convinced special casing the situation where a model in passed in argument is the right choice. I understand that the most obvious place to call django.setup() is at the top of the task function and at this point arguments have already been unpickled. This explains how we came up with the current code. We didn't realize that "unpickle a model before app loading has completed" could happen in other scenarios. Regardless, I'm skeptical of this hack. I would expect task runners to provide some sort of initialization hook. For rq, the documentation explains how to "provide your own worker script" to run initialization code. I believe this is something django-rq could easily abstract. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2CEA8A48-18C8-4FB1-A965-A14C6B6E5A4D%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
Re: Improving MSSQL and Azure SQL support on Django
There has not been much direct progress with regards to an SQL Server database backend. My personal life keeps getting in the way and the test suite takes a disturbingly long time on my computer against MSSQL. Despite me being busy, others have helped move things forward. Some have contributed code to django-mssql and others have put effort towards optimizing the Django test suite so that it doesn't take so long when connecting to a MS SQL Server. My goal for the next MSSQL database backend will be to support running Django on Windows, Linux, and Mac. Support for Windows is one of my primary concerns because there are existing production sites that run Django on Windows. Regards, Michael Manfre On Wed, Jan 27, 2016 at 12:15 AM, Cristiano Coelho wrote: > I'm interested in the progress of this as well :) > > Sorry I didn't read through all the posts, mostly the first ones about the > idea. > > I would like to know, have you guys decided on which adapter to use? I > have had a project where we needed to connect to SQL Server from a linux > machine (actually amazon lambda) and even worse, we couldn't install any > library with dependencies on C code, so we used one that was implemented in > pure python that worked very well (pytds if I'm not wrong), with ofcourse, > not the best performance. > Why do I tell this? Because even if you want django to run on SQL Server, > it doesn't really mean you want to run it on a Windows machine, actually, > that would probably be a terrible idea (no ofense), since apache works > horribly bad on Windows, and Linux is atually the best OS to run a web > server with python code (either nginx or apache). So please keep this in > mind when chosing a connector, since if it has C dependencies (which it > will probably have, since the pure python ones are quite slow). > > About if you need different connectors for Azure or SQLServer, I'm > 'almost' sure you don't, we use azure or other cloud based sqlserver > deployments with no problem with standard sqlserver connectors. > > So basically, do not aim this towards making django more Windows friendly, > but rather the actual SQL Server backend. > > > El lunes, 25 de enero de 2016, 22:59:07 (UTC-3), Fabio Caritas Barrionuevo > da Luz escribió: >> >> is there any update about the progress of this? >> >> -- >> Fábio C. Barrionuevo da Luz >> Palmas - Tocantins - Brasil - América do Sul >> >> >> >> Em terça-feira, 13 de outubro de 2015 18:12:55 UTC-3, Tim Graham escreveu: >>> >>> If anyone is interested in listening in on the meetings with Microsoft >>> engineers (Wednesday and Thursday 9am-5pm Pacific), let me know and I'll >>> send you the Skype link. >>> >>> On Friday, October 2, 2015 at 11:53:17 AM UTC-7, Meet Bhagdev wrote: On Thursday, October 1, 2015 at 12:32:25 PM UTC-7, Tim Graham wrote: > > Hi Meet, > > I was wondering > > 1. If you have any progress updates since your last message? > * Yes, engineers on my team I are currently ramping up on the three Django-SQL Server adapters* - * Django-pymssql* - * Django-pyodbc-azure* - * Django-mssql * * The goal is to have a thorough understanding of what’s good and what’s bad with these adapters before the event. * > > 2. If you have any further details on the schedule for the time in > Seattle in a week and a half? (including video conference details for > those > unable to attend in person) > - *We will have a video conference link for Day 2 and Day 3. Participants interested can join the conference stream from their browser. The conference room mics are only capable to a certain extent. Thus the quality might be a little poor. * - *We are finalizing the detailed schedule this week and will post it on this thread by next Friday. * 3. If myself or the other attendees should do anything to prepare for > the meetings? > > *Here are some things that you should prepare before coming to Seattle.* *-* - * Have a clear understanding of the things that you need from Microsoft to improve the SQL Server support on Django. We have resources to do the heavy lifting but need guidance. * - * Share with us the issues we can help fix (on the Django side and on the Django-ORM(database) side). * Thanks! > > On Thursday, September 17, 2015 at 3:38:09 PM UTC-4, Tim Allen wrote: >> >> Hey team, as promised, here are the simple tests I put together to >> benchmark pyodbc vs pymssql. Be kind, this was Python I wrote a long time >> ago! >> >> https://github.com/FlipperPA/pyodbc-pymssql-tests >> >> I've included example output on the README. Very basic, but useful. >> >> On Wedne
uri to iri encoding
Hi,I had a doubt.RFC 3987 stated that the percent encoding corresponding to
% , i.e '%25' must not be converted to its octet while converting the uri
to its iri.So then the output of uri_to_iri("%2525") should be what ,
"%2525" itself?Currently it gives %25 as the output.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/59eac34a-632e-4595-b971-9dad0a52b9fb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Provide a way for model formsets to disallow new object creation
In #26142, we want model formsets to be able to disallow new object
creation. Users try to do this by supplying extra=0, but this does not
prevent the web client from adding more forms to the POST data.
https://code.djangoproject.com/ticket/26142
For non-model formsets, this can be achieved by leveraging the existing
attributes validate_min and validate_max on the Formset. I propose the
following simple implementation that adds can_create, defaulting to
True, which when set to False, sets validate_{min,max} to True,
{min,max}_num to the number of initial forms, and extra to 0.
https://github.com/django/django/pull/6053
For model formsets, this does not seem to be sufficient, as the primary
keys need to be validated as well.
Any comments on this approach or ideas for an alternate way?
I am not sure how to proceed with extending the model formsets.
Best,
Mathias Rav
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/20160127212404.GA12110%40gonzales.mama.local.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
Re: View permissions to admin
Hi Petr, all, I managed to find some time to look into your PR (updated link: https://github.com/django/django/pull/5297) and the related issue: https://code.djangoproject.com/ticket/8936 . Also, related discussion: https://groups.google.com/d/topic/django-developers/rZ5Pt9R94d4/discussion and issues: https://code.djangoproject.com/ticket/820 and https://code.djangoproject.com/ticket/17295 First of all, thank you for your your contribution and persistence. I think Django should provide an easy way to get a read-only view of your data in the database. However, I don't really like the integration into contrib.admin . As it stands now, people commonly use the admin as a front end for their employees instead of building a proper process-oriented interface. This may work to some degree but it's not uncommon that developers need to fiddle with the internals of the admin to make specific things work. Adding a read-only view to the admin would encourage people even more to use the admin for reasons where they shouldn't. I'd prefer an approach on a different level where Django gains a proper (de)serialization implementation. The implementation would e.g. leverage content negotiation to define the output, e.g. JSON, XML, HTML, etc. What I'm pretty much saying is, I'd rather see a proper django.rest (or whatever we wanna call it) instead of a feature on top of the convoluted admin which provides only half of what people probably want and use. Cheers, /Markus On Wednesday, August 26, 2015 at 9:49:58 PM UTC+10, Petr Dlouhý wrote: > > Hello all, > > I am still waiting for some information about what should I do next to get > this pulled into Django. Isn't here somebody willing to take a look at this? > > PR is at https://github.com/django/django/pull/5108 > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ef3d364c-3e80-4883-b4ac-378661582e07%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
