Re: Improve adding data to forms programmatically
Am 17.09.2015 06:24, schrieb Yo-Yo Ma: > To clarify, are you referring to a state where there are validation errors > and the form is redisplayed, whereupon your change the value back to the > original value? No, there don't have to be validation errors. I want to redisplay the form to the user even if there were none. > Pertaining the problem you mentioned last (displaying the intermediary > result): you are probably better off using the value from the form's instance > for displaying outside of an input. What do you mean by "the value from the form's instance"? -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/55FA8331.2030006%40googlemail.com. For more options, visit https://groups.google.com/d/optout.
Re: Why leave explicit null=True when blank is True in IntegerField, DateField etc?
That kind of implicit behavior would just leave things more confused. Writing a few characters less code isn't a benefit if it comes at the expense of making the behavior less obvious. -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0e56558e-0efd-467f-8b08-75e20c5e6fae%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Improving MSSQL and Azure SQL support on Django
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 Wednesday, September 16, 2015 at 11:27:59 AM UTC-4, Tim Allen wrote: > > Thanks for all of your efforts, Aymeric, I've been following your project > since its inception - I'm FlipperPA on GitHub. > > On Sunday, September 13, 2015 at 4:59:34 AM UTC-4, Aymeric Augustin wrote: >> >> Did you mean “pyodbc outperforms pymssql”? Or did you go with pyodbc >> despite lower performance? (Or did I misread that?) >> > > We went with pyodbc, despite lower performance. I've been meaning to put > the simple tests up on GitHub - making a note to do that this week. > > At the time we were looking at options, we couldn't find a stable Django > option for pymssql. I should have been more clear about the time frame in > which we were testing as well; this was right around the time that you > first started django-pymssql. > >> >>- django-pymssql is basically django-mssql on Linux. We could debate >>whether django-pyodbc-azure is more stable than django-mssql. There’ve >> been >>a bunch of forks over the years. >> >> >> I’m not going to argue it further because I would inevitably sound like >> I’m tooting my own horn which isn’t my intent. I will just say that the >> picture isn’t all that clear. >> > > There is definitely much more to consider now, than when we were first > assessing options. I will say I've been impressed with django-pyodbc-azure > staying up to date with Django's releases. > > From the perspective of someone who works on Django’s internals, I believe >> django-pyodbc-azure could use a review of how the Django database backend >> API is implemented. >> >> For example, looking at the new transaction APIs I introduced in 1.6, I >> see that it commits or rolls back implicitly in _set_autocommit. At best >> that’s weird and useless, at worst a data corruption bug. >> >> Nothing that couldn’t be fixed, but just because the code works doesn’t >> means it handles edge cases well. django-mssql probably fares a bit better >> since its author cooperated with and eventually joined the core team. >> >> Thanks to the abstraction provided by the Python DB-API, it should be >> quite easy to port code implementing Django’s database backend API between >> django-mssql and django-pyodbc-azure anyway. >> > > You certainly know this stuff more intimately that me, I can just relay my > experience, and hope it helps! Either way, a driver provided from Microsoft > that offers better performance, easier installation and configuration, and > more features would be a win for us all. The amount of time I've seen > people spend trying to get FreeTDS + unixODBC + pyodbc running is > substantial. > > Thanks again for your efforts - they're very much appreciated, and I'll > check out django-pymssql again soon, it has been over a year. > > Regards, > > Tim > -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d54bc172-6c90-407e-a0aa-591fb280c0cf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Adding a URL tagging feature
I've received a few comments on Ticket #25409 and so I'm opening up the
discussion here.
The pull request is https://github.com/django/django/pull/5309
Apologies for the long post, just wanted to be as clear I could!
The objectives of the discussion are to determine:
1. Is this something that could be merged in before the other URL
re-factoring work (
https://groups.google.com/d/topic/django-developers/9AqFxIIW2Mk/discussion)
I personally think that we can as the code changes are minimal.
2. Does this approach conflict with/complement/replace the 'decorators'
approach proposed in the URL rework project. There is a comparison of the
pros and cons of each approach below. Looking at the code on that branch it
appears simple for me to be able to merge it in there.
== Synopsis ==
Often (usually in middleware) processing has to be applied to certain URLs
only eg CORS.
The usual way to specify this would be to create an additional set of regex
patterns identifying these urls - eg.
CORS_URLS_REGEX = r'^/api/2/.*$'
JSONP_URLS = r'^/api/1/.*$'
PRIVATE_URLS = r'/(private|api)/.*$'
Each middleware then typically matches the incoming request URL to the
regex and determines whether it is to be selected for processing by it.
This approach has several limitations including:
* It violates DRY as the regexes in the settings have to be synced with the
actual URL patterns
* Matching multiple patterns either requires the user to create complex
regexes or the app/middleware writer has to essentially reinvent URL
patterns - poorly.
== The Proposal ==
Add an optional *tags* keyword argument to django.conf.urls.url allowing a
URL to be optionally tagged with one or more tags which can then be
retrieved via HttpRequest.resolver_match.tags in the middleware / view (or
any code with access to urlpatterns - not necessarily in the context of a
request). Probably easiest to explain via examples:
urlpatterns = [
url(r'^$', views.home, name='home'),
url(r'^private/$', include(private_patterns), tags=['private']),
url(r'^api/1/', include(api_v1_patterns), tags=[
'api', 'private', 'jsonp',
]),
url(r'^api/2/', include(api_v1_patterns), tags=[
'api', 'cors', 'private',
]),
]
api_v1_patterns = [
url(r'^list/books/$', views.list_books, name='list-books'),
url(r'^list/articles/$', views.list_articles, name='list-articles',
tags=['public]),
...
]
api_v2_patterns = [
url(r'^list/books/$', views.list_books, name='v2-list-books'),
url(r'^list/articles/$', views.list_articles, name='v2-list-articles',),
...
]
In the above patterns all URLs under /private/ are tagged 'private', all
URLs under /api/1/ are tagged 'api', 'jsonp' and 'private'.
Some examples to show how you can access and use tags
Example Middleware:
class PrivatePagesMiddleware(object):
def process_view(self, request, view_func, view_args, view_kwargs):
"""
For any url tagged with 'private', check if the user is
authenticated. The presence of a
'public' tag overrides the 'private' tag and no check should be
performed.
Authentication depends on whether the URL is marked as 'cors' or
not. 'cors' urls
use HTTP header token authentication
"""
tags = request.resolver_match.tags
if 'private' in tags and not 'public' in tags:
if 'cors' in tags:
# CORS requests are authenticated via tokens in the headers
# check auth tokens
...
if not authenticated:
return HttpResponseForbidden()
elif not request.user.is_authenticated(): # normal django auth
return redirect('login')
class CorsMiddleware(object):
def process_view(self, request, view_func, view_args, view_kwargs):
if 'cors' in request.resolver_match.tags:
# continue CORS processing
def process_response(self, request, response):
if 'cors' in request.resolver_match.tags:
# continue CORS processing
Example Management command:
commands/exportapi.py
"""
Javascript API code generator
Iterate through urlpatterns, for each url tagged with 'api' export a
Javascript function
that allows js code to call the api function. Depending on whether the
pattern is tagged
'jsonp' or 'cors' write the corresponding type of function
"""
def get_api_urls(urlpatterns, api_type):
for pattern in urlpatterns:
# check if pattern has the 'api' tag and the api_type tag
if is_api_type:
yield pattern
class Command(BaseCommand):
def handle():
for api_pattern in get_api_urls(urlpattrns, 'jsonp'):
# write JSONP javascript function to stdout
for api_pattern in get_api_urls(urlpattrns, 'cors'):
# write CORS javascript function to stdout
manage.py exportapi > api.js
-
The actual code c
