Re: Improving MSSQL and Azure SQL support on Django
Hi Tim,
Thanks for sharing your experience!
> On 13 sept. 2015, at 01:48, Tim Allen wrote:
> We have a test suite performing table creates / destroys, basic CRUD
> operations, stored procedure execution, and more against both pyodbc and
> pymssql.
> pymssql outperforms pyodbc significantly against SQL Server, especially on
> SELECT and INSERT operations.
Did you mean “pyodbc outperforms pymssql”? Or did you go with pyodbc despite
lower performance? (Or did I misread that?)
> pymssql on Linux offers no stable Django options, as noted throughout this
> thread.
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.
> pyodbc offers several options.
> we initially started using django-pyodbc (lionheart on GitHub), which worked
> but required quite a few tweaks to the settings.
> we moved to django-pyodbc-azure, which we found a much easier install /
> Django DATABASES {} configuration, and is kept up to date in a timely fashion.
>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.
--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/A38482C5-64CF-4E3F-B86C-E60956678B6C%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.
Concerns with new "libraries" template functionality
I was reading through the 1.9 release notes when I came across the new
OPTIONS['libraries'] feature.
Relevant links:
-
https://docs.djangoproject.com/en/dev/releases/1.9/#template-tag-modules-are-imported-when-templates-are-configured
- https://docs.djangoproject.com/en/dev/releases/1.9/#templates
-
https://docs.djangoproject.com/en/dev/topics/templates/#module-django.template.backends.django
*tl;dr*
This new functionality trades convention for configuration, in a
problematic way, for little gain.
If OPTIONS['libraries'] was made to mean: "only these libraries can be used
in templates", there would be no problem. If it does in fact mean this,
please disregard the following points and view this as a documentation
update request.
*Long version:*
My concern is that we're now offering a way to explicitly register template
libraries in OPTIONS['libraries'], which:
1) allows you to {% load some_key_from_that_dict %}
2) causes the modules to be loaded upon application start (and
presumably `check`)
Unless I missed something, this functionality is lacking / concerning
because of the following reasons:
1) 'libraries' will not be the *only* libraries allowed to be used in
your templates, which *removes the "explicit"* nature (there isn't much
explicit about a setting that is only additive)
2) Due to #2, you can still run into module load time errors via {%
load something_not_registered %}
3) Environment-specific settings module (e.g., local_settings.py) can
now cause unexpected runtime errors due to renaming tag libraries (vs
simply using the module name)
4) 'libraries' will not be automatically built-in ('builtins' does that)
#4 is only mentioned because when you consider #1, #2 and #3 there is
suddenly no additional value added by this "libraries" option, unless it
also acted as add_to_builtins.
If the goal of this feature is to add application start time checks for
template libraries, the right (and *consistent*) way to handle this would
be to follow suit with admin.py, models.py, tests.py, etc., and add
`templatetags` packages to application checks. If the goal of this feature
is to provide a way to control the name used in {% load ... %} (very small
value added, IMHO), then this should be the only thing it does, so that
devs don't rely on the feature for something more.
If I'm understanding this new feature correctly, the *elevator pitch*
becomes:
*You can now use OPTIONS['libraries'] to have Django check for import
errors on *some* of your template libraries, the ones you remember to add
there. The side effect is that {% load some_name_that_isnt_a_module_name %}
will confuse devs. Also, your devs can continue to use {% load
by_module_name_not_libraries_key %} and ignore your settings completely, or
even worse, if they have local template settings due to local file system
differences, they will have to remember to copy new libraries in each time
they're added / changed.*
--
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/2bfe1c14-c4a7-4fc9-a9f7-b77a4f7d35ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Concerns with new "libraries" template functionality
CORRECTION: | Due to #2, you can still run... Should be: | Due to #1, you can still run... -- 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/0485d9ad-0736-4042-8aaa-f89a79d2df51%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Ability to migrate other applications
Hi, On Thursday 10 September 2015 17:00:07 Emmanuelle Delescolle wrote: > As this thread is most likely leading to a dead-end, let me try to close it > by summarizing it: Not trying to re-open the thread, just that... > > Shai: This seemed a little far from what I said (or, at least, intended): > You feel strongly against this code as it subverts the whole idea behind > migrations. No, it only subverts the validation of conflicts introduced by parallel lines of development. Essentially the same concern as you attributed (correctly) to Markus and myself together. > However you would enjoy this feature if it was called "project migrations" > instead and, maybe, eventually, (if I understand the name of the feature > correctly) if the feature was automated rather than manual (project > migrations created directly inside the project instead of having to move > them yourself and add the extra line in it) > Naming is important, but there's a little more to that too: Current migrations, and you do not propose to change that, are managed as if each only affects its own app. Project migrations would have tooling around them -- generation, validation and execution -- that takes into account that they affect more. > > Shai and Markus: > You are both very concerned about multiple leaf migration trees and about > the fact that those leaf migrations might clash with each other. > After deeper thinking, this concern is probably more than legitimate but > has, also probably, very little to do with the current proposal. If running > makemigrations creates a new migration for an app you didn't write, it will > end-up being a leaf migration independent of whether you leave it in your > venv or are able to move it to your project and exposes you to the "clash" > risks all the same. > ... except that when all the migrations are in the same app, DJango already has mechanisms to detect and warn users against these clashes. True, the tools are blunt and require the user to make the decision about actual clash-or-no- clash, with almost no aid beyond pointing out the possibility of the clash. But this is still a lot better than the completely silent clashes your suggestion enables. > > About modeltranslation: > I, personally, am not too found of apps using contribute_to_class either so > if anyone knows of an app which allows me to have translations for > user-generated content living in my database (as those are translations for > content from the database) which is pluggable on third party apps and > doesn't require an extra join on (almost) every query, please let me know, I'm not sure if it works with modern Django -- last time I looked it was updated to Django 1.2, and I haven't had to deal with translations in the database for several years now -- but I always thought django-dbgettext had it right. Its strategy was to pull specified database strings into .po files so you can translate them just like you translate strings from your source. (Oh, upon looking I see that it did get some attention last year. Good). HTH, Shai.
Re: Concerns with new "libraries" template functionality
Hello,
The situation is nowhere near as complicated as you make it sound.
1) Builtins: many applications or projects relied on the private
`add_to_builtins` API in order not to have to {% load %} commonly used
libraries in every template. The new “builtins” option provides a public API
for this purpose.
2) Libraries: it can be inconvenient to create an application just for
registering a library. Also that doesn’t make sense when using the template
engine outside of Django, which is possible since I refactored it as a library.
The new “libraires” option provides an alternative for these use cases. The
current convention remains to allow pluggable apps to provide template tags
(and for backwards-compatibility).
See https://code.djangoproject.com/ticket/17085
and
https://github.com/django/django/commit/655f52491505932ef04264de2bce21a03f3a7cd0
for details.
You’re saying that this change “trades convention for configuration, in a
problematic way”. But it only adds options and doesn’t remove anything; nothing
is being traded.
I suspect that you’re confused about the ability to “{% load
some_key_from_that_dict %}”. Libraries registered in the libraries option must
be loaded exactly as if they had been registered with @library.register.
If you think the docs could be clarified, patch welcome!
--
Aymeric.
> On 13 sept. 2015, at 16:13, Yo-Yo Ma wrote:
>
> I was reading through the 1.9 release notes when I came across the new
> OPTIONS['libraries'] feature.
>
> Relevant links:
>
> -
> https://docs.djangoproject.com/en/dev/releases/1.9/#template-tag-modules-are-imported-when-templates-are-configured
> - https://docs.djangoproject.com/en/dev/releases/1.9/#templates
> -
> https://docs.djangoproject.com/en/dev/topics/templates/#module-django.template.backends.django
>
> tl;dr
>
> This new functionality trades convention for configuration, in a problematic
> way, for little gain.
>
> If OPTIONS['libraries'] was made to mean: "only these libraries can be used
> in templates", there would be no problem. If it does in fact mean this,
> please disregard the following points and view this as a documentation update
> request.
>
> Long version:
>
> My concern is that we're now offering a way to explicitly register template
> libraries in OPTIONS['libraries'], which:
>
> 1) allows you to {% load some_key_from_that_dict %}
> 2) causes the modules to be loaded upon application start (and presumably
> `check`)
>
> Unless I missed something, this functionality is lacking / concerning because
> of the following reasons:
>
> 1) 'libraries' will not be the *only* libraries allowed to be used in
> your templates, which removes the "explicit" nature (there isn't much
> explicit about a setting that is only additive)
> 2) Due to #2, you can still run into module load time errors via {% load
> something_not_registered %}
> 3) Environment-specific settings module (e.g., local_settings.py) can now
> cause unexpected runtime errors due to renaming tag libraries (vs simply
> using the module name)
> 4) 'libraries' will not be automatically built-in ('builtins' does that)
>
> #4 is only mentioned because when you consider #1, #2 and #3 there is
> suddenly no additional value added by this "libraries" option, unless it also
> acted as add_to_builtins.
>
> If the goal of this feature is to add application start time checks for
> template libraries, the right (and consistent) way to handle this would be to
> follow suit with admin.py, models.py, tests.py, etc., and add `templatetags`
> packages to application checks. If the goal of this feature is to provide a
> way to control the name used in {% load ... %} (very small value added,
> IMHO), then this should be the only thing it does, so that devs don't rely on
> the feature for something more.
>
> If I'm understanding this new feature correctly, the elevator pitch becomes:
>
> You can now use OPTIONS['libraries'] to have Django check for import errors
> on *some* of your template libraries, the ones you remember to add there. The
> side effect is that {% load some_name_that_isnt_a_module_name %} will confuse
> devs. Also, your devs can continue to use {% load
> by_module_name_not_libraries_key %} and ignore your settings completely, or
> even worse, if they have local template settings due to local file system
> differences, they will have to remember to copy new libraries in each time
> they're added / changed.
>
> --
> 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 g
Making the admin compatible with CSP
Ticket #15727, dealing with adding support for the Content Security Policy header, was last updated with the suggestion that the one thing should be done is to make the admin site compatible by removing inline scripts. I'd love to see this done, especially with the new design. I have done a similar job on my own django site so had a quick look at the admin. And it seems manageable, but I might be missing things due to naivety. I'm just looking for opinions before I start. I'm gonna try get a pull request together in the next day or two. There is not a huge amount of inline scripts and in general I see three problems to solve. 1) inline scripts to autofoucs a field when the page loads 2) inline scripts that pass data from django to javascript 3) scripts that use href="javascript" I'd propose solving as follows 1) use the autofocus attribute when creating the form. This will work for IE10+ http://caniuse.com/#feat=autofocus It can also be done by including a creating a few targeted one line js files and including instead of the inline. It just seems a lot of http overhead to save users of two old browsers having to click into a text input. 2) use https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet#HTML_entity_encoding Quick example from popup_response.html