Re: Improving MSSQL and Azure SQL support on Django

[Dmitriy Sintsov]

Microsoft probably will take Django support to the next level with Windows 
Subsystem for Linux. It's still beta but a very promising one. Not only it 
should make compiling Python module binaries (like lxml) much easier, it 
also fixes binary / nix specific support of node.js / Ruby packages.

On Friday, April 28, 2017 at 10:55:26 PM UTC+3, uri...@gmail.com wrote:
>
> I wonder if there have been any updates on MS support for a 
> official/supported MS SQL Django driver? Did the offered engineering effort 
> from MS ever come through? Given the availability of of MS SQL on Linux, as 
> well as support for Django in Visual Studio, it would be great if this came 
> to fruition.
> Explicit support for Django with IronPython would also be nice, if MS 
> would really want to take their Django support to the next level...
>
> On Monday, March 7, 2016 at 5:37:06 PM UTC-5, Meet Bhagdev wrote:
>>
>> Hi all,
>>
>> On interacting with several Django developers and committers, one of the 
>> questions often came up, can I use SQL Server on non Window OS's? I wanted 
>> to share that today Microsoft announced SQL Server availibility on Linux - 
>> https://blogs.microsoft.com/blog/2016/03/07/announcing-sql-server-on-linux/
>> . 
>>
>> While there is still work needed to strengthen the MSSQL-Django story, we 
>> hope this aids more Linux developers to give SQL Server a shot. Let me know 
>> of your thoughts and questions :)
>>
>> Cheers,
>> Meet
>>
>> On Monday, February 22, 2016 at 4:54:38 PM UTC-8, Vin Yu wrote:
>>>
>>> Hey Folks, 
>>>
>>> My name is Vin and I work with Meet in the Microsoft SQL Server team. 
>>> Just wanted to let you all know we are still looking into how we can better 
>>> improve and support MSSQL for the Django framework. We’ll continue to sync 
>>> with Michael and let you know of any updates soon. 
>>>
>>> Christiano and Tim - thanks for sharing your interest and sharing how 
>>> you are using Django with MSSQL. It's great to learn from your scenarios. 
>>>
>>> If you have any concerns, questions or comments feel free to reach out 
>>> to me at vinsonyu[at]microsoft.com
>>
>>

-- 
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/80728ca3-efe3-42c4-a131-8e99a0c40576%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Admin and CSS Custom Properties

[Dmitriy Sintsov]

CSS variables are long time available at server-side via LESS / SASS 
compilers. For example MediaWiki has built-in ResourceLoader that includes 
LESS compiler and JS minifier. It uses caching to re-compile only when 
source .less or .js are changed. Everything works even with IE8. But 
MediaWiki is an "out-of-box use" software not a framework like Django.

When changing colors, most easy way is to use Bootstrap for admin 
templates. In such way, changing colors is as easy as dropping bootstrap 
skin into 'static/css/bootstrap_skin.css' and specifying it with 
Admin.Media subclass css attribute. There are lots of ready bootstrap 3 
skins as well as bootstrap editors. Also it works with old IE and no CSS 
variables are needed (they are compiled separately from Bootstrap source 
code).

On Friday, April 28, 2017 at 3:00:36 PM UTC+3, Collin Anderson wrote:
>
> I suggest supporting IE11+, as that's the latest on Windows 7 and there's 
> not much 9-10 usage. Now's probably a good time to bump them if needed 
> because we're just past an LTS.
>
> Though, yes, it doesn't allow CSS variables.
>
> On Fri, Apr 28, 2017 at 6:38 AM, Curtis Maloney  > wrote:
>
>> I recently discovered that the stated "policy" on browser support in 
>> Admin is... well... not clear at all.
>>
>>
>> https://docs.djangoproject.com/en/1.11/faq/admin/#what-browsers-are-supported-for-using-the-admin
>>
>> It claims to support full function for "YUI's A-Grade" browsers, but the 
>> link it provides does nothing to explain the supported versions, and a 
>> further "target environments matrix" link still lists IE6.
>>
>> So perhaps it's time to update the FAQ, and have a discussion on what 
>> Admin's browser support policy needs to be updated to.
>>
>> --
>> Curtis
>>
>> On 28/04/17 19:14, Patrick Guido wrote:
>>
>>> On 27 April 2017 at 23:18, Adam Johnson 
>>> > wrote:
>>>
>>> Thanks for introducing me to a new CSS feature! I clearly don't keep
>>> up with front end stuff enough.
>>>
>>> Re: your issues:
>>>
>>> 1. From the support grid at the bottom of the Smashing Magazine
>>> article you linked, it looks like it's only IE 11 and Edge 14 that
>>> are major browsers that don't support it. However I feel like if
>>> Django is going to announce a feature like "you can override the
>>> Admin colours", it should work in all browsers. I'm not sure if we
>>> have a written policy for this though.
>>>
>>> I guess it also depends on use cases, usually (where I work) we tend to
>>> support only latest browsers when it comes to admin, since
>>> it will be used by only a few people :) But I see your point.
>>>
>>> A friend of mine was suggesting configuring colours in python, but this
>>> means that the css would be rendered via python, which is
>>> not ideal.
>>> Another solution would be to add a JS polyfill to make it work on older
>>> browsers, but I'm against it :)
>>> Let's also keep in mind that this (if approved) will be included in
>>> django 2.0 or later, so the browser support will be even better :)
>>>
>>>
>>> 2. I'm not a huge fan of an additional HTTP request for every admin
>>> page load, for every admin site in existence whether or not the
>>> colours have been overridden. HTTP/2 isn't very widely deployed
>>> still so requests still ain't cheap.
>>>
>>> Uhm, I think we can easily skip one request if the colours have not been
>>> overridden. We can put the vars in base.css.
>>> Then we can add the variables by changing the template (but that's more
>>> cumbersome) either by adding an external css link
>>> or by adding a style tag with the variables.
>>>
>>>
>>> 3. This can be overcome with a test to ensure the two files are in
>>> sync, I guess?
>>>
>>> Uhm, true!
>>>
>>>
>>> And one more question: how much less painful is this to override the
>>> colours compared to the variable-less way, where you just clone the
>>> colour definitions of every rule in the original file in a second
>>> override file?
>>>
>>> I haven't checked all the rules, but I think it will require quite a bit
>>> of work. Maybe we can create a "template" file
>>> that can be used to override quite easily the colours, but that doesn't
>>> scale too well I think.
>>>
>>>
>>> --
>>> Patrick Guido Arminio
>>>
>>> --
>>> 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-develop...@googlegroups.com 
>>> .
>>> To post to this group, send email to django-d...@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/CAOUxZcugkWEnyx3wt7uXNYJE_Rgix-5N_iPw

Re: DEP pre-proposal for a simpler URLs syntax.

[Emil Stenström]

Hi everyone!

I got curious to the current state of this work so I thought I save 
everyone some work and give you a bunch of links:

   - Main PR where the work is being done: 
   https://github.com/django/django/pull/7482 - Seems there are conflicts 
   with master that needs to be resolved.
   - An update to all documentation to use path() instead of url(): 
   https://github.com/django/django/pull/7542
   - PR for an updated DEP 0201: https://github.com/django/deps/pull/34

*Tome Christie* and *Sjoerd Job Postmus* have done a hell of a good job 
here! I'm trusting that they ask for help if there's something the 
community can do.

If this gets merged it will be one significant improvement to Django!

/Emil

On Monday, 3 October 2016 12:24:04 UTC+2, Tom Christie wrote:
>
> Hi folks,
>
> I wanted to push forward the consideration of introducing a simpler URLs 
> syntax, plus support for URL parameter type conversion.
>
> A pre-proposal is available here: 
> https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98
>
> At this point I'm seeking feedback, before hopefully iterating on the 
> proposal, and making a formal submission.
>
> I'm not making any assumptions right now about where this might get too, 
> or who'd be involved if it does make it to the DEP stage, and would very 
> much welcome outside involvement. I'm also aware that while there's been 
> some positive reception, it's not yet clear if we'll reach a consensus on 
> inclusion in core.
>
> Personally I'm very firmly +1 on this, as I feel that the existing syntax 
> is a rather glaring and unnecessary pain point.
>
> Thanks to everyone who's started to kick this off, in particular Emil 
> Stenström for raising the original thread, and Sjoerd Job Postmus for their 
> work on the Django Simple URL 
>  package.
>
>   - Tom
>

-- 
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/6a64deca-fbbf-4a8c-a510-6f2c1ab30f22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Easier way to populate test databases for parallel tests (patch in github)

[Shai Berger]

On Saturday 29 April 2017 03:50:16 Tim Graham wrote:
> I would expect test data population to happen using migrations rather than
> in the test runner. Can you elaborate on your use case and say if that
> method would be unsuitable?
> 

Apparently, many people think that migrations are the wrong tool for this job.

See previous discussion, which didn't seem to go anywhere:

https://groups.google.com/d/msg/django-developers/Ln1-IqysEwE/DuyZl7QkEwAJ

Have fun,
Shai.

Re: Easier way to populate test databases for parallel tests (patch in github)

[Adam Johnson]

Avoiding migrations, one can populate test data with a post_migrate signal
handler. django.contrib.contenttypes already does this to fill the DB with
content types, see
https://github.com/django/django/blob/c651331b34b7c3841c126959e6e52879bc6f0834/django/contrib/contenttypes/apps.py#L18
. To do it during tests only you could have a condition to register said
handler.

On 29 April 2017 at 09:39, Shai Berger  wrote:

> On Saturday 29 April 2017 03:50:16 Tim Graham wrote:
> > I would expect test data population to happen using migrations rather
> than
> > in the test runner. Can you elaborate on your use case and say if that
> > method would be unsuitable?
> >
>
> Apparently, many people think that migrations are the wrong tool for this
> job.
>
> See previous discussion, which didn't seem to go anywhere:
>
> https://groups.google.com/d/msg/django-developers/Ln1-IqysEwE/DuyZl7QkEwAJ
>
> Have fun,
> Shai.
>



-- 
Adam

-- 
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/CAMyDDM3zT5h_6eLfkresqwaKr%2BbXESSaH5V5PXNikbUz3ufdtQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Easier way to populate test databases for parallel tests (patch in github)

[Marcos Diez]

I believe I was not clear.

I do use migrations to populate Enums and other data that should also be 
available in production.

The code I am sending is to load fixtures on the database.

This way all tests can assume the same set of data and we all the fixtures 
are loaded in one place, which in my case of use it makes sense.

The advantage of the method I am proposing is that it is quite fast. Data 
is loaded only once in the DB and that it is duplicated in bulk mode by the 
DBMS, as many times as necessary when tests run in parallel. 

Another unexpected convenience of my method is that a developer who uses 
Django to populate fixtures in the database, does not have to worry if 
his/her code to generate data has side effects or not if he is running 
tests in parallel, because his data generation code will run only once.


Actually, if I may ask, how else would one load bunches of fixtures in the 
DB and run tests in parallel without my PR ?


-- 
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/32df6bec-a2ce-494e-b007-5f4433ad682f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Easier way to populate test databases for parallel tests (patch in github)

[Adam Johnson]

>
> Actually, if I may ask, how else would one load bunches of fixtures in the
> DB and run tests in parallel without my PR ?
>

As I said, register a post_migrate handler during testing that loads your
data. It will run during the creation of the first database in
connection.creation.create_test_db, as part of call_command('migrate'),
before the test runner code clones the database for parallel execution.
There's no need to change Django to support this.

Another option is that you extend your database backend and override
creation.create_test_db and add logic there.

By the way, I think it's the general opinion that tests are best *without* a
large generic fixture available to them. It's certainly been my experience,
as it makes it very hard to later understand *what* data a specific test
does or does not rely upon, and if the data can be updated safely. The tool
I prefer for test data generation is factory boy (
https://factoryboy.readthedocs.io/en/latest/ ) which can be used to create
data per test method or class, without having to laboriously specify every
field of every model.

On 29 April 2017 at 13:36, Marcos Diez  wrote:

> I believe I was not clear.
>
> I do use migrations to populate Enums and other data that should also be
> available in production.
>
> The code I am sending is to load fixtures on the database.
>
> This way all tests can assume the same set of data and we all the fixtures
> are loaded in one place, which in my case of use it makes sense.
>
> The advantage of the method I am proposing is that it is quite fast. Data
> is loaded only once in the DB and that it is duplicated in bulk mode by the
> DBMS, as many times as necessary when tests run in parallel.
>
> Another unexpected convenience of my method is that a developer who uses
> Django to populate fixtures in the database, does not have to worry if
> his/her code to generate data has side effects or not if he is running
> tests in parallel, because his data generation code will run only once.
>
>
> Actually, if I may ask, how else would one load bunches of fixtures in the
> DB and run tests in parallel without my PR ?
>
>
> --
> 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/32df6bec-a2ce-494e-b007-
> 5f4433ad682f%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

-- 
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/CAMyDDM0vEu2fTXfGCFhhTtVZ7rJOrOSKYDFT6Sb%2B%2Bh%3DAs5Z9TA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - April 29, 2017

[Tim Graham]

Triaged

---

https://code.djangoproject.com/ticket/28121 - force_text incorrectly 
handles SafeBytes under PY3 (wontfix)

https://code.djangoproject.com/ticket/28131 - Template variable "perms" 
single-attribute lookup does not work as documented (accepted)

https://code.djangoproject.com/ticket/28125 - Clarify 1.11 release notes 
about which Template class prohibits non-dict contexts (fixed)

https://code.djangoproject.com/ticket/28130 - Formset validate_min 
validation ignores unchanged forms (accepted)

https://code.djangoproject.com/ticket/28150 - Behavour of 
django.utils.text.slugify is not consistent between Python 2 and 3 when 
passed a tuple (wontfix)

https://code.djangoproject.com/ticket/28148 - Document addition of 
validate_image_file_extension() as a backwards incompatible change for 
ImageField (accepted)

https://code.djangoproject.com/ticket/28123 - 
django.utils.html.smart_urlquote() is incorrectly parsing the query string 
(wontfix)

Authored

--

https://github.com/django/django/pull/8401 - Fixed #28040 -- Updated 
SplitArrayWidget to use template-based widget rendering.

https://github.com/django/django/pull/8403 - Fixed #28122 -- Fixed crash 
when overriding views.static.directory_index()'s template.

https://github.com/django/django/pull/8426 - Fixed #28130 -- Fixed formset 
min_num validation with initial, unchanged forms.

Reviewed/committed

--

https://github.com/django/django/pull/8265 - Fixed #27996 - Added 
RandomUUID function and CryptoExtension to contrib.postgres.

https://github.com/django/django/pull/8319 - Fixed #27644 -- Doc'd 
FileSystemStorage.get_created_time()

https://github.com/django/django/pull/8299 - Fixed #27730 -- Doc'd that 
template vars created outside a block can't be used in it.

https://github.com/django/django/pull/8415 - Fixed #28137 -- Deprecated 
HttpRequest.xreadlines().
https://github.com/django/django/pull/8320 - Fixed #28037 -- Clarified that 
QueryDict.items()/values() are generators.

-- 
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/1e3f0d34-e353-4af8-b3a6-e67329e29dd3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.