Re: Django Sites framework

[Michael Manfre]

Adding "SITE_ID = 1" to your settings will get you past the exception
without having to add it to INSTALLED_APPS. I had to do this one of my
projects.

On Aug 21, 7:02 pm, Vladimir Prudnikov  wrote:
> Yep, django.contrib.sites is not included in the INSTALLED_APPS list.
>
> On 21 Aug 2009, at 10:40, David Christiansen wrote:
>
>
>
> > Have you checked your INSTALLED_APPS for the sites app as well?
>
> > On Aug 20, 10:59 am, Vladimir Prudnikov  wrote:
> >> I'm *not* using Sites framework ('django.contrib.admin' is not
> >> included in INSTALLED_APPS and SITE_ID is not defined), but there is
> >> an exception when I click on "View on website" link on the edit model
> >> page in admin interface.
>
> >> Exception Value:         You're using the Django "sites framework"  
> >> without
> >> having set the SITE_ID setting. Create a site in your database and  
> >> set
> >> the SITE_ID setting to fix this error.
>
> >> There is no check that Sites framework is really used.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

#12250 Feedback Request

[Michael Manfre]

If a middleware throws an exception, it is not possible to catch and
handle that error. Instead it goes straight to the unhandled exception
handler and prevents any process_exception middleware methods from
acting on the exception. I included a patch that shifts the
process_view processing down a line of code to allow middleware
exception handling.

#12250 http://code.djangoproject.com/ticket/12250

Regards,
Michael Manfre

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #12250 Feedback Request

[Michael Manfre]

Scanned all the 6000 tickets for "exception" and found it (#6094).
Didn't find that when I searched before creating the ticket.

--
Michael Manfre

On Dec 9, 11:22 pm, Alex Gaynor  wrote:
> On Wed, Dec 9, 2009 at 11:21 PM, Michael Manfre  wrote:
> > If a middleware throws an exception, it is not possible to catch and
> > handle that error. Instead it goes straight to the unhandled exception
> > handler and prevents any process_exception middleware methods from
> > acting on the exception. I included a patch that shifts the
> > process_view processing down a line of code to allow middleware
> > exception handling.
>
> > #12250http://code.djangoproject.com/ticket/12250
>
> > Regards,
> > Michael Manfre
>
> > --
>
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-developers?hl=en.
>
> This is actually a duplicate of another ticket (who's number I can't
> recall, but it is in the 6000 range).
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your
> right to say it." -- Voltaire
> "The people's good is the highest law." -- Cicero
> "Code can always be simpler than you think, but never as simple as you
> want" -- Me

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Final call for feedback: Multi-db

[Michael Manfre]

With multiple database defined, what is the expected behavior for
syncdb and the other db related commands? The documentation shows that
it is relatively easy to associate an admin form with a given
database, but is there a way of associated a model or app to a given
database?

Regards,
Michael Manfre

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Django-mssql with the dream of passing the test suite

[Michael Manfre]

A few weeks ago, I started down the path of updating django-mssql so that
it supports Django 1.4. I moved the project over to bitbucket (
http://bitbucket.org/Manfre/django-mssql/), docs are deployed to read the
docs (http://django-mssql.readthedocs.org), and have made it a policy of
deploying packages to PyPi.

Django 1.4 support is mostly there and so far is passing all testing for
the site responsible for the backend's existence (http://www.src.org). To
help avoid surprises and ensure life as a 3rd party database backend
maintainer is a lot less painful, I have set a goal of having django-mssql
pass the test suite. This is a non-trivial task that will require changes
to django and django-mssql. I've already submitted a few tickets that bring
me closer to my goal and it was advised that I send this message as a heads
up regarding my intentions to avoid tickets being closed with a "mssql
isn't officially supported by Django" comment.

If you review one of these tickets, please keep my goal in the back of your
mind. I welcome feedback on better ways of approaching my proposed changes.

Regards,
Michael Manfre

-- 
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: Django-mssql with the dream of passing the test suite

[Michael Manfre]

Thanks for the heads up. I'm getting very close to having the test suite 
pass. After I accomplish that goal and establish a more solid reference 
point for django-mssql, I'll look in to the work you've done with adodbapi.

Regards,
Michael Manfre

On Thursday, May 17, 2012 10:14:23 AM UTC-4, VernonCole wrote:
>
> I should mention that if you use pywin32 build 215 or newer, an 
> appropriate version of adodbapi will already be included.  You do not need 
> to download it separately from sourceforge or PyPi unless you are running 
> IronPython. Since pywin32 is already a dependency for django-mssql, you 
> should be covered.  Also, it should not be too hard to add support for 
> ACCESS and 3rd party databases.
> --
> Vernon
>
> On Wednesday, May 16, 2012 2:27:00 PM UTC-6, Michael Manfre wrote:
>>
>> A few weeks ago, I started down the path of updating django-mssql so that 
>> it supports Django 1.4. I moved the project over to bitbucket (
>> http://bitbucket.org/Manfre/django-mssql/), docs are deployed to read 
>> the docs (http://django-mssql.readthedocs.org), and have made it a 
>> policy of deploying packages to PyPi. 
>>
>> Django 1.4 support is mostly there and so far is passing all testing for 
>> the site responsible for the backend's existence (http://www.src.org). 
>> To help avoid surprises and ensure life as a 3rd party database backend 
>> maintainer is a lot less painful, I have set a goal of having django-mssql 
>> pass the test suite. This is a non-trivial task that will require changes 
>> to django and django-mssql. I've already submitted a few tickets that bring 
>> me closer to my goal and it was advised that I send this message as a heads 
>> up regarding my intentions to avoid tickets being closed with a "mssql 
>> isn't officially supported by Django" comment.
>>
>> If you review one of these tickets, please keep my goal in the back of 
>> your mind. I welcome feedback on better ways of approaching my proposed 
>> changes.
>>
>> Regards,
>> Michael Manfre
>>
>

-- 
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/-/NPgGiBa2iegJ.
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: Proposed Field API additions

[Michael Manfre]

On Thursday, June 7, 2012 4:16:12 PM UTC-4, Alex Ogier wrote:
>
> This isn't particularly robust. The SQL string generated by a 
> particular backend isn't considered part of any API, and might change 
> formatting or semantics on minor updates. Some SQL is quite 
> complicated and dubiously related to the particular field, such as 
> extra INDEX or UNIQUE constraint statements. Certain backends elide 
> some arguments, performing constraint checking in the application (the 
> sqlite backend for example just drops many constraints). In general, 
> you want the migrations to be DB-agnostic, and checking SQL output 
> loses this feature. 
>
>
While the entire raw SQL generated by a field may be too unstable to 
inspect, the underlying SQL shouldn't be completely ignored. At the very 
least, the datatype needs to be inspected when freezing to detect if the 
rug has been pulled out from under the ORM.

A real world use case. Django-mssql uses the datetime datatype for datetime 
fields. Several years ago, Microsoft made the recommendation that all new 
work should use datetime2. A future version of django-mssql will switch to 
using datetime2. It would be great if the proposed migration framework 
handled that sort of switch, or at the very least displayed a warning about 
the need for manual user intervention.

The same type of problem could be encountered if a database backend becomes 
unsupported and users are forced to switch to another backend where the 
maintainer follows a different set of "best practices". There are many ways 
of storing the same data that are all completely valid. The most likely 
problem field will be IPAddressField due to varchar(15) vs. unsigned int.

Regards,
Michael Manfre

-- 
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/-/OzJ6JJwJxsYJ.
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: use SQLAlchemy Core for query generation

[Michael Manfre]

On Tuesday, July 3, 2012 9:42:28 AM UTC-4, Luke Granger-Brown wrote:
>
> In new versions of virtualenv the default has changed to 
> --no-site-packages, at least on Linux. Is this not also the case for 
> Windows? 
>
> Luke
>
> Unfortunately, it is the same for windows. Every python project that I run 
on windows has PIL or pywin32 as a dependency, which requires me to 
remember to add "--system-site-packages", else it breaks (and not always in 
a way that is detected immediately).

--
Michael Manfre

-- 
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/-/kgVhijIl39IJ.
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: Djonet, the MonetDB backend for Django

[Michael Manfre]

I haven't tested your patch or backend and only have a few comments on 
implementation ideas for a custom database backend.

On Monday, July 9, 2012 11:25:47 AM UTC-4, Gijs Molenaar wrote:
>
>
> These problems are:
>  * MonetDB supports a Decimal type with a maximum length of 18 digits.
>

Override DatabaseOperations.value_to_db_decimal and clamp the max_digits to 
18. I'm not sure if you'll need other modifications.
 

>  * No support for hyphens in column names
>

Hyphens are not allowed even when the column name is quoted? If so, strip 
then you can strip them out in DatabaseOperations.quote_name.
 

>  * No support for != operation (only <>).
>

You'll need to provide your own SQLCompiler and do the substitution there. 
You can look at django-mssql's implementation [1] as an example.

[1] 
https://bitbucket.org/Manfre/django-mssql/src/eff1ed275fdd/sqlserver_ado/compiler.py


Regards,
Michael Manfre

-- 
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/-/e40h8NaEZZIJ.
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: Djonet, the MonetDB backend for Django

[Michael Manfre]

On Thursday, July 19, 2012 10:15:50 AM UTC-4, Gijs Molenaar wrote:
>
> hi Michael,
>
> Thanks for your response! One more question, see below.
> But the test script has != hardcoded in it, is it the idea that you scan 
> every query for such character combination? Isn't this bad practice since 
> it will have a performance impact since it is performed on all queries?


Correct. You need to check and fix all queries. The overhead of a single, 
compiled regex replace per query should be negligible. The django-mssql 
backend does a lot more lifting than that for any query with aggregates or 
slicing.

Regards,
Michael Manfre

-- 
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/-/cKMiQzb3-04J.
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: Djonet, the MonetDB backend for Django

[Michael Manfre]

On Mon, Jul 30, 2012 at 9:32 AM, Gijs Molenaar wrote:

>
> Hi Michael,
>
> Op dinsdag 10 juli 2012 17:51:16 UTC+2 schreef Michael Manfre het volgende:
>>
>>
>> On Monday, July 9, 2012 11:25:47 AM UTC-4, Gijs Molenaar wrote:
>>>
>>>
>>> These problems are:
>>>  * MonetDB supports a Decimal type with a maximum length of 18 digits.
>>>
>>
>> Override DatabaseOperations.value_to_**db_decimal and clamp the
>> max_digits to 18. I'm not sure if you'll need other modifications.
>>
>>
>
> This doesn't seem to solve the problem. This only limits the convertion of
> Decimal types to 18 digits, but not the creation of the table itself. I
> Think the correct place to define such a things would be do something
> with DatabaseCreation.data_types. Any suggestions?
>

DatabaseCreation.data_types allows you to set a format string that should
be used for the various types. I'm not sure how you could use that to
change either max_digits or decimal_places to clamp them for MonetDB. You
could monkey patch DecimalField or provide your own field that enforces the
DB's limit, but I think it would be easier from a maintenance standpoint to
document the limitation. People have full control over the models that they
use in their projects, including from 3rd party apps. Silently changing the
database schema is probably not a good policy to take.

--
Michael Manfre

-- 
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: Djonet, the MonetDB backend for Django

[Michael Manfre]

On Tue, Jul 31, 2012 at 6:50 AM, Gijs Molenaar wrote:

>
> If you don't mind I have an other question, I hope you have the time to
> share your thoughts on this one also. I'm digging trough all the test cases
> and fixing them, but i'm a bit stuck on this one. test_forward_refs
> (modeltests.serializers.tests.JsonSerializerTransactionTestCase) fails in
> my case, generating a foreign key constrain violation. I've
> set supports_forward_references to False in features, but doesn't seem to
> have any effect. Do you have any interesting suggestion?
>
> Thanks!
>
>  - Gijs
>

I vaguely remember encountering a problem with forward references when I
was adding support to django-mssql for Django 1.4. Can you post the
traceback? It might jog my memory.

--
Michael Manfre

-- 
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: The key of permissions model

[Michael Manfre]

Instead of get_permission('app_label.permission_name'), why not punt on the 
problem
until schema migrations lands. Only provide a plural helper method that 
always returns 
a list. The first argument could be either a string or a list of strings. 
This leaves it up to
the caller to determine what to do if more than one is returned when they 
only expected
a single result. Having all of the conflicts is a lot more useful than the 
"returned more than
1" exception.

Regards,
Michael Manfre

On Wednesday, September 19, 2012 6:41:25 PM UTC-4, Anssi Kääriäinen wrote:
>
> We use the style of "app_label.permission_name" in multiple places of 
> our code to refer to given auth.models.Permission. However, there is 
> no unique key for that combination, the key is content_type, 
> permission_name. I verified that it is actually possible to hit this 
> problem by using the Meta.permissions. 
>
> I am not sure what we can do about this... Or if we even need to do 
> anything about this. 
>
> Without schema changes we can't have a DB constraint for the key. But, 
> maybe we could validate (as part of model validation) that there are 
> no overlapping permissions? If the user goes and creates overlapping 
> permissions despite of this, we can't do anything about that. 
>
> The reason why I am wondering about this is that I'd like to add 
> Permissions.objects.get_permission('app_label.permission_name') 
> convenience method. And, while investigating that I realized that the 
> app_label, permission name isn't a key... 
>
> I am likely going to add the get_permission() anyways, it will just 
> throw "returned more than 1" if the above problem is hit. 
>
> Thoughts? 
>
>  - Anssi 
>

-- 
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/-/_ool0iQ7kKwJ.
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.

SQLCompiler.as_sql with_col_aliases

[Michael Manfre]

Is it safe to assume that the with_col_aliases argument of 
SQLCompiler.as_sql is intended to only be True when the query is a 
subquery? Those are the only usages I've found in the code.

MSSQL only supports ordering subqueries under a limited number of 
circumstances. To fix the SQL in django-mssql's compiler, I need a clear 
way of identifying when the query is a sub-query. If this is not a safe way 
of using with_col_aliases, is there another?

Regards,
Michael Manfre

-- 
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/-/56Tv7DEP3EkJ.
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: Why doesn't DjangoProject.com downloads provide a Windows installer like web2py does?

[Michael Manfre]

As some one who develops and hosts a Django project on Windows, Runserver 
and sqlite are more than enough to get potential Django converts through 
the tutorial and a few test projects. When they're ready to work on a more 
substantial project, then they'll start to get a bit more immersed in 
database choices, hosting, and all the other tools that help make the 
workflow a bit less clunky.

One of the biggest problems I've encountered with the open source project 
installers for Windows is that they lag behind, most likely being more 
effort than the community is able to devote towards the windows installer. 
Even Apache httpd is facing this with 2.4. Having an outdated Windows 
installer can be more off putting than having no installer at all. I've 
ignored projects for that reason in the past; memcached was one of those 
projects for a while.

I think Windows users would be better served with a little bit more 
documentation about getting up and running on Windows. To start the 
tutorial you only really need to install python, install setuptools, and 
then install django. Providing some insight about tools that are mostly the 
equivalent to those available on *nix platforms would be useful as the new 
user progresses beyond the tutorial. I'd be willing to help with a 
documentation effort, primarily by answering questions since I'm not sure 
if I have enough availability to do much more than that. 

The slides from my "Django on Windows" PyCarolinas talk might be helpful 
for some Windows users after they get past the initial install. 
http://manfre.github.com/django-on-windows-talk/

Having a linux VM dedicated to Django development was painfully slow on my 
modestly powered desktop. Any benefits were quickly lost by a laggy UI. It 
might have been better if I was able to get a folder mapped so I could use 
an editor on the host Windows system, but I deleted the VM prior to 
devoting enough time to figure that out.

Regards,
Michael Manfre



On Saturday, December 22, 2012 7:28:39 PM UTC-5, Kevin Veroneau wrote:
>
> I am posting this here as I feel it is related to the development of 
> Django, since it is related to it's distribution to end-users.
>
> Something that web2py has provided for a long time is a nice Windows 
> installer to help Windows users start using web2py right away with 
> zero-effort, similar to how WAMP works for PHP developers on Windows.
>
> I believe, it would be most beneficial for the Django website to provide 
> such an option.  I bet most Windows users who hear about Django visit the 
> website, but don't see a download link for their system.  These users will 
> either seek help on how to set it up or it will deter them from exploring 
> Django further.  The latter is what we, as a community do not want to see.  
> We would like prospect developers to at least explore the development 
> environment and see what it's all about before making the choice of not 
> using it
>
> For a time, there was a project called InstantDjango, it wasn't very well 
> known, but it did the job of containing a Python/Django installation into a 
> single directory which was portable and be easily deleted or moved onto a 
> USB drive.  The project maintainer has since removed the website from 
> existence, along with the tutorials and download links he provided.  
> Fortunately, I retained a copy of this and now host it on my blog with an 
> updated version of Django.
>
> With the guidance of the main Django developers, I would like to perfect a 
> distributable Windows installer for the greater Django community.  Perhaps 
> starting with Django 1.5, the community can also provide an easy Windows 
> installer for test driving Django on a Windows machine, and for local 
> Windows development.  I can volunteer to maintain this port, with guidance 
> from the other developers on how to distribute it and package it.  The goal 
> of this is to provide Windows users with an option to test drive Python and 
> Django with minimal knowledge and risks.  Installing Python and Django in 
> Windows does require a fair amount of work and command-line knowledge, 
> which may scare some Windows users away from this great framework.  Think 
> of how easy WAMP is to install and use for PHP developers, I want Django to 
> have this ease of use as well.
>
> Disclaimer:  I am a full-time Debian Linux user, but have attempted to 
> install Python/Django on Windows in the past.  I can understand what some 
> Windows users go through during this ordeal.
>
> Link to retained InstantDjango(for example purposes): 
> http://www.pythondiary.com/blog/Apr.10,2012/instant-django-release-information.html
> I plan on updating this InstantDjango with Django 1.5, and using 
> distribute over setuptools.  Current Download count: 

Re: Switch to database-level autocommit

[Michael Manfre]

On Tue, Mar 5, 2013 at 4:42 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> In practice, this would mean:
> - Define "hook points" that are a superset the old and the new APIs.
> - Re-implement the current transaction management with these "hook points"
>   (hard, because the intended behavior of the dirty flag isn't clear).
> - Implement the new transaction management  with these "hook points"
>   (hard, because that prevents using Python's context manager abstraction,
>   which maps exactly to atomic blocks and guarantees that the exit method
>   is always called).
> - Add checks to prevent invalid operations when mixing the old and new
> APIs,
>   this is extremely difficult to get right when there are many hook points.
> - Provide simple guidelines on how the old and new APIs may be mixed.
> - Ensure that the old API can be trivially removed, because the author of
> the
>   new code may not be there in two years.
>
> This looks possible, but not in the amount of time I'm able to spend
> volunteering for Django.  If someone wants to implement this, I'll put my
> branch on hold. Otherwise, I'll propose it for inclusion into core.
>
> --
> Aymeric.


Don't forget about doubling the number of tests that need to be run for
each database backend to ensure both old and new work as expected.

Supporting multiple APIs simultaneously seems like it would be very
tedious, error prone, and add additional constraints on how the overall
transaction management can be improved, assuming it's even possible to do
both simultaneously in a stable way. The superset API would be less clean
and would add more support overhead for all of the backends, not just
MySQL.

This question may have an obvious answer, but it has yet to be asked. What
is the likelihood that people will actually benefit from being able to flip
a setting to convert from old to new transaction management, instead of
just stopping on Django 1.5 until they are ready to make the transition to
whatever backwards incompatible changes exist in Django 1.6?

If there is a new superset API, then anyone using a 3rd party database
backend will be left behind until the backend gets around to implementing
the new API. To give a little perspective as a 3rd party database backend
maintainer (django-mssql), I'd probably just drop support of the old
behavior as soon as I made the changes to support the new. Even if the
superset API should theoretically just work for both, there will be more
testing, support issues, and code complexity to ensure both APIs work as
expected. I don't really have the time or motivation to support a
transition state that guarantees additional API changes (removal) in the
future.

>From reading this thread, I also feel like the arguments in favor of the
parallel old and new support has not really been justified. It's a huge
body of work for an small edge case. The arguments also seem to provide a
strong justification for revisiting the idea of moving database backends
out of the core. I don't want to sidetrack this thread, I'll start a new
thread momentarily, but I think the idea is relevant for the current
discussion and should help decide which way to proceed.

Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Moving database backends out of the core

[Michael Manfre]

Full disclosure, I maintain django-mssql and am biased toward having all
database backends treated as if they were 3rd party backends.

The current discussion about "Switch to database-level autocommit" (
http://bit.ly/ZlVERI) reminded me of a past discussion regarding moving the
database backends out of the core. I don't remember exactly where I heard
the discussion, but I'd like to revive it. My proposal is to move all
database backends out of Django, except for an sqlite reference
implementation.

Django has already done a similar transition with
django.contrib.localflavor, which provides us with some of the basic
answers about whether this sort of thing is possible and a rough guide
about how to make it happen.


Benefits
==
  - One of the biggest benefits of this change would be that database
backends will no longer be bound to Django's release cycle and Django would
not need to make a dot release for a database specific issue.

  - This will result in Django having a more flexible/robust database API.
Any of the existing complexity imposed on the core by a specific database
backend could be abstracted out to the API.

  - In some instances this will simplify the core's code by pushing the
complexity in to the specific database backend.

Concerns
===

These are the current issues/concerns faced by 3rd party database backends.

  - All backends would need to support multiple versions of Django, or at
least properly document which versions of Django the backend works with

  - People will need to (pip) install the database backend that they want
for each project

  - Less popular database backends may get left behind

  - Each project will have its own tests and will also need to run against
the entire Django test suite

Migration Path:
===

I believe this can be accomplished without needing a multi-version
deprecation cycle because unlike localflavors, there should be very little,
if any, user code that imports a specific database backend directly. The
only instances I can think of are the DATABSE_ENGINE path and non standard
features that I've added to django-mssql; custom field types, non-standard
aggregates, etc. If a multi-version deprecation cycle is needed, it will be
possible to fix the import paths as localflavors.

Django 1.6 or 1.7
  - Create separate github project for each database backend and move code
  - Abstract out any backend specific code in the ORM by extending the
database API
  - Move backend specific tests to appropriate project

Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Moving database backends out of the core

[Michael Manfre]

On Tuesday, March 5, 2013 3:31:59 PM UTC-5, Florian Apolloner wrote:
>
> Hi,
>
> While I agree that moving database adapters out of core has some merit, I 
> don't think that having sqlite as a reference implementation is a good 
> idea: For one some features are somewhat hacky in sqlite (and people tend 
> to copy from reference implementations, so it should be as clean as 
> possible) 
>

I think I made a mistake in using the word "reference". "Included" would be 
a more accurate definition of its intended status. Ideally, no database 
backends would be in the core, but I realize that is not entirely practical 
because of the need to run tests. Sqlite also provides the lowest barrier 
for new users to get through the tutorial.

>From my experience of maintaining django-mssql, I usually have to reference 
all of the backends depending on the issue I'm working on. I start by 
looking at whichever database provides the closest behavioral match and 
then compare it to the others. Every database is different, so it's not 
like copy & paste is going to happen. Database backends are also not 
something a large number of people will run out and create. I imagine that 
even with Postgres, mysql, and oracle in separate projects they will still 
be maintained by a collection of developers that will most likely include 
core devs.
 

> and it's lack of data validation makes it imo a nogo.
>

The lack of data validation is definitely a nogo for production sites, but 
imo sqlite in production is also a nogo.

The reference implementation should imo also have strong support for GIS, 
> which is somewhat okay on sqlite but quite hard to install. So if we were 
> to do that I'd either vote for postgres or supporting postgres and sqlite 
> inside of core (the later solely for fast tests).
>

. I've never tried to install GIS for sqlite, but is the difficulty due to 
lack of documentation or just sheer number of steps?

Regards,
Michael

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Moving database backends out of the core

[Michael Manfre]

On Tuesday, March 5, 2013 5:01:01 PM UTC-5, Florian Apolloner wrote:
>
> Hi Shai,
>
> On Tuesday, March 5, 2013 10:32:29 PM UTC+1, Shai Berger wrote:
>>
>> In recent years, I have been the main contributor to South's MSSQL and 
>> Oracle 
>> backends. I am biased towards having MSSQL treated as an equal to the 
>> database 
>> systems supported in core, but also towards support of backend-specific 
>> low- 
>> level code in user apps. Also, I am a Linux user -- I use django-pyodbc 
>> for my 
>> work on South, not django-mssql. 
>>
>
> I am obviously biased against postgres as my previous post indicated, but 
> regardless of that I think that MSSQL should stay outside of core. No 
> core-developer I know actually uses Windows as base OS and to my knowledge 
> no one uses MSSQL. This would put the expected support for South below what 
> we have for Oracle currently.
>

I agree that MSSQL should stay out of the core. I believe that adding any 
more database in to the core would be a large step in the wrong direction.
 

> And where the dependency is weaker, being in core was not a 
>> guarantee for fixes -- Django carried significant Oracle problems for 
>> quite 
>> long, and they were just not deemed crucial. 
>>
>
> Now that we test on Oracle once again I am committed to have a full 
> passing testsuite with 1.6 (whatever that means, since I don't use Oracle 
> on a daily base I can't say what a running testsuite actually means for a 
> project).
>

Is it not possible to maintain the same standard with it as a separate 
project? Automated tests could still easily be accomplished and the only 
real difference about the backend working with Django is that the releases 
of the projects would not be a direct blocker for each other. 3rd party 
backends are only able to provide eventual support. Sometimes the new 
behaviors are in place ahead of the Django release, sometimes it lands 
shortly after. A huge benefit is that if there is a bug/change in the 
postgres backend, it doesn't require another Django release.
 

> I am worried that the result of such change will not be that MSSQL is 
>> treated 
>> as well as Postgres is today, but that Oracle is treated as bad as MSSQL 
>> is 
>> today. 
>>
>
> That might as well be true, if Oracle is outside of core I personally 
> wouldn't put much effort in fixing stuff there (this obviously might change 
> depending on whether I use Oracle at work or not). 
>

Having a backend outside of core might encourage others to step up and 
maintain it, especially if they depend on it. I'm sure many currently have 
the mentality of "the cores will take care of it, so I don't have to". 

It sounds as if Oracle is already not really a supported database and will 
only have a passing test suite. As you stated, "whatever that means, since 
I don't use Oracle on a daily base I can't say what a running testsuite 
actually means for a project".

Regards,
Michael

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Moving database backends out of the core

[Michael Manfre]

Hi Andre,

On Tuesday, March 5, 2013 5:39:29 PM UTC-5, Andre Terra wrote:
>
> If I may weigh in on the matter as an outsider, if we consider "The Django 
> Project" as a "business", insofar as it aims to have as many users and be 
> as ubiquitous as possible, there's considerable value in having MSSQL 
> included in core. If it were up to me, I would develop on Linux using 
> postgres and host everything on Heroku, but at work I'm restricted to 
> corporate rules, MS SQL or Oracle, and Windows. 
>

Business rules dictate Windows and MSSQL for me as well. Despite the fact 
that including MSSQL in the core would mean it has a better bare minimum 
amount of support, I'm strongly opposed to it being included. The core 
already has too many databases included.
 

> I have a strong feeling that by embracing Windows as a first-class 
> platform for developing and running Django, we're enabling current and 
> future users to easily integrate the framework in existent business 
> infrastructure, which can only be seen as a good thing for the project.
>

Agreed. Windows should be treated as a first-class OS, but I don't think 
any of the core devs use Windows as their primary OS. I only know of one 
core dev that even runs the Django testsuite on Windows from time to time.

Regards,
Michael

>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Moving database backends out of the core

[Michael Manfre]

On Wed, Mar 6, 2013 at 12:47 PM, Florian Apolloner wrote:

> On Wednesday, March 6, 2013 3:32:45 PM UTC+1, Michael Manfre wrote:
>>
>> The lack of data validation is definitely a nogo for production sites,
>> but imo sqlite in production is also a nogo.
>>
>
> Right, but shipping Django with a non production db might send interesting
> signals to endusers ;)
>

It might, but it's all about marketing. "Django, now 10% less monolithic!"

Regards,
Michael

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: deprecate and remove django.contrib.comments

[Michael Manfre]

On Thursday, March 7, 2013 1:05:53 PM UTC-5, Alex Ogier wrote:
>
> I think it can't just disappear. Even if you can't find a maintainer, core 
> should put at least a little effort to make sure that an API compatible 
> third-party application exists that is compatible at least through version 
> 1.8 when "import django.contrib.comments" stops working (basically, do the 
> work ourselves to make sure that it doesn't rely on undocumented internals 
> and can be cleanly split). Then, if it's not maintained, it can fester and 
> stop being compatible with new Django versions or whatever. If it's really 
> not important enough to anyone that it can stay modern outside of core, 
> then it will die, but we should make it a trivial matter to fork and adopt 
> for whoever needs it.
>

This approach sounds a lot better than just booting it from the repo.

Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Moving database backends out of the core

[Michael Manfre]

On Thu, Mar 7, 2013 at 8:13 PM, Russell Keith-Magee  wrote:

> I completely agree with Jacob's analysis of the status quo, and I agree
> largely with his position on having MSSQL in the core.
>
> I'd have no problem seeing MSSQL in the core - it's at least as high
> profile as Oracle, and although the demand for a MSSQL backend is
> restricted to a particular subset of the community, there is at least
> *some* demand for it to exist. Having MSSQL in core would allow us to hold
> our head high and say we support Microsoft platforms. Microsoft is even a
> member of the DSF at this point, so they're at least notionally interested
> in Django as a platform.
>

/slightly off topic
I didn't realize they were a DSF member. I have been wanting to set up
Jenkins to run the test suite on Windows with the ultimate goal of getting
its results added to ci.djangoproject.com. Knowing that Microsoft is a DSF
member will probably help gain access to a VM on Azure to make that a
reality. I've so far managed to get an introduction to a PM on one of the
Azure teams to help get a more direct answer to some Django, Windows, and
SQL problems that have been raised to my attention.

/back on topic

The maintenance burden is the problem. Historically, we've already had to
> *remove* a MSSQL backend because of bit rot (see [1]) - this isn't a
> pattern I want to repeat in the future. I don't want to add a backend to
> core unless I'm *certain* that it will see long term maintenance.
>
> [1] https://github.com/django/django/commit/c30a050e41
>

The demand for MSSQL would probably increase if it were included in core
because companies could be more confident about its ongoing support.

There are three options for using MSSQL with Django; django-pyodbc,
django-mssql, or write your own. The third option is not really a viable
option for most users.

django-pyodbc is cross platform, but not updated very often and has limited
stored procedure support. The official repo on Google code was last updated
in 2011, but there is a github fork with its last commit 8 months ago.

django-mssql is actively maintained and will be for at least the next few
years because it's used for my employer's production site that is critical
to business operations. The backend also supports stored procedures almost
to the same extent as a Windows business application. The only real
downside to the backend is that it only works on Windows, reducing its
usefulness to a much smaller, but growing, minority of Django users.

If Django wants to "hold [its] head high and support Microsoft platforms",
then I'm willing and capable of helping out with MSSQL and Windows support.
The only real caveat is that my employer needs me to maintain a certain
level of stored procedure functionality, so if MSSQL were included in the
core by using django-pyodbc instead of django-mssql, I would only be able
to commit personal time toward maintaining it, instead of also being able
to set aside business hours.

There is, however, a possible middle ground, following the example set by
> Flask: we introduce to Django a list of "officially recognised" extensions.
> These extensions are still maintained as external projects, but the core
> team promise to include these projects as part of the testing regimen for a
> release. If the MSSQL backend were recognised like this, we would run the
> full Django test suite against the MSSQL backend, and if that testing
> revealed a bug in the test suite which was identified as being due to a
> change in Django's codebase, that bug would be a release blocker (Bugs in
> the backend itself would still be the backend's responsibility, and not
> release blocking on Django)
>

This is sort of the idea I had in mind for backends while I was typing up
this proposal. You articulated it better than I did. A main problem I now
see with it is if the ownership of a bug cannot be mutually agreed upon
between Django and the extension, then this could cause doubt about what it
really means to be "officially recognized".

Regards,
Michael Manfre

Since DjangoCon, I now hear the email author's voice when reading some of
these emails.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Moving database backends out of the core

[Michael Manfre]

On Fri, Mar 8, 2013 at 6:35 AM, Florian Apolloner wrote:

> What's the state of http://code.google.com/p/pymssql/ ?
>

Their stable release relies upon a no longer supported Microsoft driver and
has some known issues that make it unusable (lack of MARS support being the
biggest issue encountered in production). They've been working toward
switching to FreeTDS, but I have not actively followed their progress since
last summer and don't know how close they are to the switch. I might be
remembering incorrectly, but some of the issues with django-pyodbc's
support of stored procedures might have been rooted in FreeTDS. I haven't
reevaluated django-pyodbc for a few years because of its lack of support
and the native client drivers available to django-mssql are faster.


> If we have MSSQL in core I'd really like to be able to talk with it from a
> Linux machine too, it would also make testing easier since we'd just need a
> VBox with MSSQL ;) Supporting a commercially available product but
> requiring to run even more commercial software seems like counter intuitive
> to me.
>

Django needs a VBox running Windows for testing, regardless if MSSQL is in
the core.

Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Moving database backends out of the core

[Michael Manfre]

On Fri, Mar 8, 2013 at 9:33 AM, Javier Guerra Giraldez
wrote:

> On Fri, Mar 8, 2013 at 4:25 AM, VernonCole  wrote:
> > People tend to think of ADO as only talking to Microsoft databases.
>  Nothing
> > could be farther from the truth.  When maintaining adodbapi, I normally
> test
> > against MS-SQL Server, Microsoft "Jet" (a.k.a. ACCESS), MySQL, and
> postgres.
> > I have also personally used it to get data from IBM DB2, an Active
> Directory
> > server, and a .csv file.  If some idiot has written an odbc driver for
> it, I
> > will let you read it from Python.
>
>
> nice.
>
> does the client run on non-win32 plaforms?  from a cursory read of the
> website, adodbapi seems to require pywin32.
>

adodbapi is included with pywin32 and requires it.

Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Using EXISTS instead of IN for subqueries

[Michael Manfre]

On Monday, March 25, 2013 6:58:12 AM UTC-4, Tim Chase wrote:
>
> I can only speak for testing IN-vs-EXISTS speed on MSSQLServer at 
> $OLD_JOB, but there it's usually about the same, occasionally with IN 
> winning out. 


In SQL 2008r2, the optimizer is usually smart enough to end up with the 
same execution plan for IN and EXISTS queries. Historically, EXISTS was 
usually the faster operation for SQL Server and if memory serves it had to 
deal with its ability to bail out of the EXISTS query sooner compared to 
the IN query.

MSSQL is a 2nd-class citizen in the Django world, so I'm +1 
>

Reasoning like that helps to keep it in its place.

Anssi,

Any chance of adding a new database feature to flip the behavior of __in to 
either IN or EXISTS? Sounds like this change of logical and documented 
behavior is being made specifically because of failings with Postgresql. 
The feature would also help satisfy the deprecation cycle normally used for 
changes to documented behaviors. Sub-queries are more likely to expose 
database specific issues with the SQL provided by Django (normally when 
used with aggregates or slicing). Adding the database feature might save 
every other backend from having to potentially jump 
through unnecessary hoops (mangling more SQL).

Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Using EXISTS instead of IN for subqueries

[Michael Manfre]

On Tue, Mar 26, 2013 at 10:23 AM, Tim Chase
wrote:

> > In SQL 2008r2, the optimizer is usually smart enough to end up with
> > the same execution plan for IN and EXISTS queries. Historically,
> > EXISTS was usually the faster operation for SQL Server and if
> > memory serves it had to deal with its ability to bail out of the
> > EXISTS query sooner compared to the IN query.
>
> I'd have to go back and re-test 2008r2, as my testing was on 2005
> (and earlier). But my testing directly contradicts your
> "Historically..." bit, as I DISTINCTly (bad SQL pun intended) remember
> being surprised precisely because of what you say: EXISTS should be
> able to optimize and bail early.


My "Historically" comment is based upon memory of observed behaviors from
many years ago and could even be an ingrained memory dating back to SQL
Server 7. I'll concede that your testing is probably more accurate than my
memory of observed SQL optimizer behaviors from upwards of a decade ago.
The execution plan is a result of the specific query and schema, so it's
possible that we're both correct and both wrong at the same time.


>  EXISTS also has some nice features
> like the ability to do testing against multiple columns, i.e., you
> can't do something like
>
>   select *
>   from tbl1
>   where (col1, col2) in (
>select a, b
>from tbl2
>)
>
> but that's a simple EXISTS query.
>

Agreed, EXISTS is more flexible and at least to me, often easier to read,
format, and maintain. Assuming this is implemented with a database feature,
I'll most likely enable the EXISTS change for django-mssql. My main
objections to a blanket change is to not have the specific behaviors of one
database dictate how every other database must behave. Some one needs to be
the voice of 3rd party database backends and it appears for the time being,
I'm wearing that hat.


> > > MSSQL is a 2nd-class citizen in the Django world, so I'm +1
> >
> > Reasoning like that helps to keep it in its place.
>
> MSSQL's lack of certain core features is what does that.
> OFFSET/LIMIT provided by pretty much every other DB vendor?  Use
> baroque hacks to get the same functionality.


The non "baroque hack" way of doing limit offset is with nested selects.
Maybe someday the non-standard LIMIT/OFFSET keywords will get added to the
standard (I truly hope this happens) so Oracle, MSSQL, DB2, and Informix
could share SQL with postgres and mysql without needing to mangle it.

Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Using EXISTS instead of IN for subqueries

[Michael Manfre]

On Tue, Mar 26, 2013 at 12:40 PM, Anssi Kääriäinen
wrote:

> Hmmh, this means Oracle, MSSQL, DB2 and Informix are doing more or less
> the same thing for limit/offset support? If so, then having a more generic
> approach to this problem than having a custom compiler per backend might be
> worth it...
>

I haven't looked at the DB2 or Informix code, but Oracle and MSSQL have a
custom SQLCompiler primarily to handle constructing SQL to deal with
limit/offset. A generic approach would be nice to have, but I can't imagine
a generic way that would let me generate the "SELECT ... FROM (SELECT
ROW_NUMBER() OVER (...)) WHERE ..." monstrosity with lots of column
aliasing that I currently construct. I'm definitely interested in
brainstorming what a generic approach might look like.


> BTW there is already something like LIMIT and OFFSET in SQL 2008 standard.
> The syntax is different than LIMIT/OFFSET, and supported only by some
> vendors... See
> https://en.wikipedia.org/wiki/Select_%28SQL%29#FETCH_FIRST_clause
>

The SQL 2008 standard added FETCH FIRST, which covers the LIMIT part of the
problem, but I didn't see anything in the standard to deal with OFFSET,
which is usually the more painful part of the problem. Window functions
were added in the 2003 standard, but they can have some issues with
ordering and I don't think the standard requires a way of being able to
filter by some sort of result row number.

Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Using EXISTS instead of IN for subqueries

[Michael Manfre]

On Tue, Mar 26, 2013 at 5:47 PM, Petite Abeille wrote:

>
> On Mar 26, 2013, at 10:03 PM, Alex Gaynor  wrote:
>
> > For what it's worth, SQL2011 does define OFFSET, finally.
>

Just checked and it appears this has been implemented with SQL Server 2012.
A quick check of the other database with Django backends seems to show that
all of them have a beta or stable release with support for a simple
limit/offset syntax, with many supporting the standard defined syntax. This
might make the generic approach as simple as adding an
DatabaseOperatoins.limit_offset_sql() abstraction.

Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: URL dispatcher fallthrough?

[Michael Manfre]

On Thu, Mar 28, 2013 at 8:21 AM, Loic Bistuer wrote:

> What I would like to see:
>
> urlpatterns = patterns('',
> # Standard patterns
>  url(r'^admin/', include(admin.site.urls)),
>
> # Fallthrough patterns
> url('', include('myapp.urls'),
> url('', include('django.contrib.flatpages.urls'),
> url('', include('django.contrib.redirects.urls'),
> )
>
> Each app minds its own business and no more middleware that juggle with
> Http404.
>

Fall through URL patterns make it less clear about what view is handling a
URL. It's already known and established that you need to check middleware
for arbitrary URL handling, adding this to the URL patterns as well doesn't
feel like a step in the right direction.

Middlewares that juggle Http404 are not all bad and have the potential of
being a bit saner and faster than a URL fall through. If the dispatcher
falls through, then every URL that matches the pattern would need to hit
the database and/or include its own caching to determine if the URL is a
hit for a specific app/view. That leads to the same bit of code duplicated
in the top of almost every one of these fall through views.

With middleware, you can put all of this shared logic in a base class and
provide the ability to completely short circuit the dispatcher for known
matches. For src.org, we have a few different models with staff defined
URLs. The traditional Http404 middleware pattern was a bit repetitive and I
solved the problem with this middleware (
https://gist.github.com/manfre/5262782). The heart of the middlware is
ContentMiddleware._process(), which contains the "was this handled" logic.
The Gist includes one of the simple arbitrary URL model handlers, but we
have quite a few more.


Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: URL dispatcher fallthrough?

[Michael Manfre]

On Thu, Mar 28, 2013 at 10:28 PM, meric  wrote:
>
> Michael: How does the middleware work with other URLs that do not need to
> have fallthrough? Do you have to add them to excluded_path_patterns?
> Would like a more general description of how it works.
>

A ContentMiddleware behaves basically the same as a standard 404
middleware. If no other middleware or view handles the request, then a
ContentMiddleware will get a chance to match during the process_response
phase. Most of these middleware are a shim to a view function, but some
include logic to make faster (than the view) determinations about the user,
type of asset, the request, and whether or not the underlying views could
possibly handle request. Most of our content is subject to record level
authorization checks that result in heavy queries and reducing response
time was one of the main goals of this implementation.

There are three possible types of matches that can happen for a middleware
and a request; an explicit match, an explicit miss, and an implicit match.
An explicit miss only happens when the middleware's process() raises
Http404. An explicit match is when a response is returned, either of the
ContentHandled exceptions are raised, or a permission error is raised. The
ContentHandled exceptions allow the implementing middleware to pass back
knowledge of owned URL spaces or assets that could exist at some point in
the future. For our site, when a permission check fails, it means the
assets exists. The implicit matching happens on all other exceptions.

The type of match dictates how long to cache the knowledge about whether or
not the request was handled by the middleware. Each middleware dictates
what it means for it to match and this is often more than just the URL
pattern.

During the middleware process_request phase, any previously matched request
is immediately processed by the middleware. This short circuits the URL
dispatcher and reduces the overall response time for handling the request.
On our system, users are able to arbitrarily place assets in the URL
structure and these often overlap with the URL patterns of our views. Some
of the overlapped views have heavy look ups that could take a few hundred
ms before finding out it is and probably always will be a 404.

The excluded_path_patterns provides an easy way of explicitly missing based
upon the URL without needing to check the database. This also yields a
faster response time by avoiding any lookups when the middleware attempts
to determine "is this mine" for a new request. We also use
excluded_path_patterns to help enforce business rules about the URL space
where assets may reside. The example ManualPageMiddleware explicitly
prevents any static pages from being found under our image folder. The
underlying ManualPage model is generic and has no such restrictions for its
URL.

Also, couldn't the caching logic, (ignoring fallthrough urls for a minute),
> be implemented in a view decorator (which is also what how we do it)?
>

Basic caching logic could be worked in to a view decorator, but it will not
provide responses as quickly as my middleware. The decorated views would be
processed in order and you could end up with a request chasing just behind
expiring cache entries and having to recheck them all. My middleware is
able to check the "is this handled" cache for all of the middleware before
needing to go through the URL dispatcher and then trying each of the
middleware. You could probably get similar behavior with a decorator
wrapping several entries in urls, but it would be a bit ugly and less
flexible with cache timeouts.

Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Extending the DATABASES = {'xx': {'NAME': construct to carry additional information and / or virtual names

[Michael Manfre]

On Thu, Apr 4, 2013 at 10:10 AM, VernonCole  wrote:

> In order to meet these goals, is it reasonable to do this?: Are there
> better alternatives?
>
> 1) Assume that a Proxy based connection will be acceptable for inclusion
> in django?
>

Best way to mentally think of this is as a database engine (a.k.a. django
database backend) that connects to SQL Server, which has different
dependencies on Linux (Pyro) vs Windows (pywin32). Django core shouldn't
care, or even know about the specifics. The database backend would be the
only bit of Django that knows about the proxy or how to connect to it.


> 2) Add more keys to the DATABASES entries as needed by different backends?
> (e.g. "CONNECTION_STRING": "xxx", "PROXY_ADDRESS: "10.0.0.7")
>

The DATABASES dict provides an "OPTIONS" dict [1] that specific backends
can populate as they deem necessary. Django-mssql has a few of these [2]. I
have been contemplating adding a generic "CONNECTION_STRING" to allow full
control over the connection string that would ignore all of the other
database settings when constructing the string. SqlLocalDB with its
different connection string has so far been the only motivator for this
additional OPTIONS key.

[1] https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-OPTIONS
[2] http://django-mssql.readthedocs.org/en/latest/settings.html#options


> 3) Pass the DATABASES dictionary down-chain to the proxy? (so it gets the
> USER & PORT items, etc. and can process them itself)
>

The database backend has access to the full settings dict and would be able
to connect to the proxy and pass along whatever information is needed.


> 4) Have the proxy have additional routing information so it can add its
> own intellegence to the connection attempt?
>

The proxy and any routing logic would be contained within the specific
database backend.


> 5) (In some future time) have the backend feed back more information to
> the core, such as "I am connected to an XYZ engine, switch to the XYZ
> dialect of SQL'?
>

The database backends are responsible for providing their own SQL
translations by using a combination of custom SQLCompilers,
DatabaseOperations, and DatabaseFeatures. Trying to support many different
SQL dialects within the same database backend should be possible, but would
be complex and require maintaining additional state information on the
DatabaseWrapper and connection to allow all the various places to figure
out what it should be doing. I do this in a very limited way for
django-mssql to allow for newer features in SQL Server 2008 that do not
exist in SQL Server 2005 (e.g. microseconds).

Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Ticket 20147 - deprecate and replace request.META

[Michael Manfre]

+1 to a saner repr(request) and not having to type "HTTP_". What sort of
deprecation cycle are you thinking for this?

Regards,
Michael Manfre


On Mon, Apr 8, 2013 at 4:02 PM, Luke Plant  wrote:

> Hi all,
>
> This is already the subject of a ticket, but I didn't get a response
> yet. Basically, the idea is replace things like:
>
>   request.META['HTTP_ACCEPT']
>
> with
>
>   request.HEADERS['Accept']
>
> request.META should be deprecated and replaced with request._META,
> because it is just an implementation detail, and a really bizarre one at
> that, full of cruft from a previous generation of web applications (CGI)
> that should not be exposed in our API.
>
> Anything else needed from META should also be replaced with a sensible API.
>
> This might seem to be a big change simply for the sake of a clean API,
> but I'm more and more motivated by these thoughts:
>
> * Web development is hard enough as it is. "Explain this to a newbie
> without getting embarrassed" is a good test.
>
> * A general philosophy of pro-actively keeping things clean and sensible
> is necessary to avoid being overrun with madness long term.
>
> There is also the advantage of a *much* cleaner repr(request),
> especially in a development environment, because you don't have all the
> other junk from os.environ.
>
> The biggest problem is what to do with our test Client and
> RequestFactory, which allow specifying headers as keyword arguments
> using the CGI style of naming e.g.:
>
>   self.client.get('/path', HTTP_X_REQUESTED_WITH='XMLHttpRequest')
>
> Since keyword arguments can't have "-" in them, this is harder to
> replace. We could either leave it as it is, or add a new 'headers'
> keyword argument to these methods, deprecating **extra.
>
> The silliness has infected other places, like SECURE_PROXY_SSL_HEADER
> which follows the same CGI convention (and in each case the docs have to
> note how to do it correctly!). In this case we can detect people using
> the old style 'HTTP_' and raise a deprecation warning, and allow the
> sensible way.
>
> We would probably also need to add a few methods/attributes to
> HttpRequest to proxy the few things you need from request.META that are
> not headers, like REMOTE_ADDRESS and REMOTE_USER
>
> Is anyone strongly opposed to this? If not, in Aymeric's spirit of
> decisiveness, I'll push it forward.
>
> https://code.djangoproject.com/ticket/20147
>
> Regards,
>
> Luke
>
>
> --
> Be careful of reading health books, you might die of a misprint.
>   -- Mark Twain
>
> Luke Plant || http://lukeplant.me.uk/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Ability to save 4xx messages to database

[Michael Manfre]

>From https://docs.djangoproject.com/en/dev/howto/error-reporting/#errors

"404 errors are logged using the logging framework. By default, these log
records are ignored, but you can use them for error reporting by writing a
handler and *configuring
logging*<https://docs.djangoproject.com/en/dev/topics/logging/>
appropriately."
-

The core already provides a nice way for any app/project to log the 404's
however they desire.

Regards,
Michael Manfre


On Thu, Apr 11, 2013 at 3:09 PM, Babatunde Akinyanmi
wrote:

> Hi Javier, why no
>
> Sent from my Windows Phone
> From: Javier Guerra Giraldez
> Sent: 4/11/2013 4:30 PM
> To: django-developers@googlegroups.com
> Subject: Re: Ability to save 4xx messages to database
> On Thu, Apr 11, 2013 at 10:21 AM, Val Neekman  wrote:
> > Now, the $64 K question: is Django a good place for this?
>
> I'd say no.  the best place would be a monitoring system.
>
> a surprisingly good approach is to use rsyslog protocol, and add a
> good event storage backend to the centralizing rsyslogd. i've seen
> some examples of using Redis to store these.
>
>
> --
> Javier
>
> --
> You received this message because you are subscribed to the Google
> Groups "Django developers" 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?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: survey question: should UUID database fields be returned as instances of class "uuid"? (re: ticket 19463)

[Michael Manfre]

On Mon, Apr 15, 2013 at 1:51 AM, VernonCole  wrote:

> So -- is it worth my time to muck with direct database api support of uuid
> fields?
>

Add the support. Each database backend defines the mapping for the core
model field types (see DatabaseCreation.data_types) and any non-standard
model fields can define their own mapping by overriding Field.db_type().
The app django-uuidfield [1] allows postgres to store UUIDs as it's uuid
type and translates it to a hex string for the Django side of things. You
could easily mimic the behavior or keep it as a UUID from end-to-end.

If/when Django adds UUIDField to the core field types, each backend can
define the appropriate column type (BINARY(16), CHAR(32), uuid,
UNIQUEIDENTIFIER, etc).

[1]
https://github.com/dcramer/django-uuidfield/blob/master/uuidfield/fields.py

Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: list_filter_incremental for ModelAdmin (#19755)

[Michael Manfre]

A few questions and comments.

- The potentially huge performance hit would need to be called out in the
documentation. Hit would be from more queries and less opportunities (more
complexity) to cache filter options.

- What should happen if not all of the filters on a ModelAdmin support
being incremental? Exception, allow some filters to yield empty results, or
some other behavior?

- It might be better to add a CSS class to the filter options that would
yield and empty result. Doing so would address Augustin's comment about
finding empty results as being useful and it allows changing a filter from
"Older than 6 months" to "Older than 1 month" without having to select
"All" in between. The options could be hidden with CSS to match the
proposed behavior.

Regards,
Michael Manfre








On Thu, Apr 18, 2013 at 1:19 PM, Przemysław Suliga wrote:

> Hi,
>
> This ticket is about making `FieldListFilter`s specified in
> `ModelAdmin.list_filter` alive in sense that they change according to what
> is currently displayed in changelist.
>
> https://code.djangoproject.com/ticket/19755
>
> So these new (incremental) filters will contain only choices which when
> clicked will result in non-empty changelist.
>
> With submitted patch you can just add `list_filter_incremental = True` on
> your ModelAdmin. There are no UI changes - I don't have an opinion as to if
> there should be any.
>
> So is anyone into this idea? I'll be glad to improve the patch.
>
>
> -Przemek
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: list_filter_incremental for ModelAdmin (#19755)

[Michael Manfre]

On Thu, Apr 18, 2013 at 2:25 PM, Przemysław Suliga wrote:

>
>
> On Thursday, April 18, 2013 7:59:59 PM UTC+2, Michael Manfre wrote:
>>
>> - What should happen if not all of the filters on a ModelAdmin support
>> being incremental? Exception, allow some filters to yield empty results, or
>> some other behavior?
>>
>
> All default `FieldListFilter`s are supporting it (patch).
>
> As for custom FIlters - subclasses of `SimpleListFilter` - it could be
> made `incremental aware` but to make it really 'incremental' would be
> user's responsibility (and decision in the first place) ?
>

It would be the user's responsibility, but what would be the actual
behavior with incremental and non-incremental filters on the same page?
What should Django do? How would the user know that their filters are not
all doing the same thing?

Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Michael Manfre]

I think it's better to follow the convention used by almost every other bug
tracker and stick with WONTFIX. Changing the name will be confusing. I
think the best route forward is to not take bug status wording as a
personal offense and be happy that those that set the status almost always
give an explanation as to why the case is being closed.

Regards,
Michael Manfre


On Mon, May 13, 2013 at 12:06 PM, AK  wrote:

>  On 05/13/2013 11:23 AM, Jacob Kaplan-Moss wrote:
> > On Mon, May 13, 2013 at 2:12 AM, Chris Wilson 
> > wrote:
> >> The status WONTFIX sounds awfully rude to me.
> >
> > I've thought so, too, but every time I've tried to come up with an
> > alternate name I've failed. Any suggestions?
>
>
> WONTFIX does sound rude to me, as well. Perhaps 'onholdindefinite' can
> be used instead, the effective meaning is the same, just the term itself
> is more polite. It seems that nobody looking at it would think "I'll
> just wait for a while and surely it'll get fixed.". Instead, anyone
> needing it would think "If it is to be fixed, it's clear someone has
> to make a case for it." -ak
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Multiple template engines for Django - week 4 - DEP ready for review!

[Michael Manfre]

Overall the DEP looks really good.

It's currently assumed that BaseEngine.select_template() will scan the list
in order and return the first one it can load, but it might make sense to
explicitly state that in the DEP.

To avoid having 3rd party template engines suffering some of the same
disparity that 3rd party database backends faced, what are your thoughts on
having the jinga2 engine maintained outside of core? This would leave only
the string template reference implementation and the DTL in the core.

Regards,
Michael Manfre

On Sat, Nov 1, 2014 at 6:30 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> I’m happy to annonce that the DEP is ready for public review!
>
> Direct link, HTML:
> https://myks.org/en/multiple-template-engines-for-django/dep/
>
> Direct link, ReStructured Text:
>
> https://raw.githubusercontent.com/aaugustin/mtefd/master/multiple-template-engines.rst
>
> (I’m not reproducing it here because I don’t think email is a very good
> medium for communicating 50kB of markup.)
>
> I’ve written a bit more about what “ready” means:
> https://myks.org/en/multiple-template-engines-for-django/#2014-11-01
>
> Of course, your regularly scheduled update will also be available (in half
> an hour):
> https://myks.org/en/multiple-template-engines-for-django/#2014-11-02
>
> I’m looking forward to your feedback!
>
> --
> Aymeric.
>
>
>
> > On 26 oct. 2014, at 22:36, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
> >
> > Hello,
> >
> > I just published the third update:
> > https://myks.org/en/multiple-template-engines-for-django/#2014-10-26
> >
> > --
> > Aymeric.
> >
> >
> >
> >> On 19 oct. 2014, at 00:09, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
> >>
> >> Hello,
> >>
> >> Here’s the second update:
> >> https://myks.org/en/multiple-template-engines-for-django/#2014-10-19
> >>
> >> Best,
> >>
> >> --
> >> Aymeric.
> >>
> >>
> >>
> >> On 12 oct. 2014, at 20:31, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
> >>
> >>> Hello,
> >>>
> >>> I just posted the first update on this project:
> >>> https://myks.org/en/multiple-template-engines-for-django/#2014-10-12
> >>>
> >>> My work in progress on the DEP is available here:
> >>> https://myks.org/en/multiple-template-engines-for-django/dep/
> >>>
> >>> Feedback is welcome, especially on sections I’ve described as “done”
> in the update.
> >>>
> >>> Thanks,
> >>>
> >>> --
> >>> 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/AF442429-4EFF-4C78-804F-F47ADF453245%40polytechnique.org
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAGdCwBtp52jVbtdi13hwSG%3D90A%3DjWdj6UVzKVXhoKCHF3%2BKkXg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unicode SlugField design decision (#16501)

[Michael Manfre]

Should the unicode validated field (either options) have a different
internal type for the sake of 3rd party database backends? I'm not sure if
any currently store SlugFIeld in an ascii char datatype and would need an
easy way to differentiate.

Regards,
Michael Manfre

On Tue, Nov 4, 2014 at 8:27 PM, Tim Graham  wrote:

> I wanted to solicit feedback on the two approaches to supporting unicode
> in SlugField:
>
> 1. Added a unicode argument to models.SlugField and forms.SlugField.
> https://github.com/django/django/pull/1979
>
> 2. Added models.UnicodeSlugField and forms.UnicodeSlugField.
> https://github.com/django/django/pull/1987
>
> The patch author says, "On one hand, I like the new field approach because
> it gives us an easier upgrade path. On the other hand, it feels like I'm
> polluting django.db.models and django.forms with slightly different
> versions of something that's already there."
>
> Approach 1 does seem cleaner to me, but I'd be interested in hearing from
> those interested in this feature.
>
> Ticket: https://code.djangoproject.com/ticket/16501
>
> --
> 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/33e9747f-6ced-4710-9e59-ca128e065c5c%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/33e9747f-6ced-4710-9e59-ca128e065c5c%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAGdCwBv%3DfGD-DpG4w9Bd3_9FkcKiw_CYqhR8tJK8W1EC_zvQNg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unicode SlugField design decision (#16501)

[Michael Manfre]

We can change the internal type of SlugField for option 1 based upon
whether or not the field should be unicode. Whether or not an existing
backend stores SlugField in an ascii char datatype shouldn't dictate
whether we go with SlugField(unicode=True) or UnicodeSlugField(). Let me
rephrase the question as, Do we want to provide backends enough information
so that they can decide to store an ascii slug field in an ascii char field
(e.g. varchar) and a unicode slug field in a unicode char field (e.g
nvarchar)?

On Wed, Nov 5, 2014 at 7:15 AM, Marc Tamlyn  wrote:

> It feels to me more like an option to SlugField and I feel
> UnicodeSlugField is a bit ugly. If however we find an example where
> Michael's point is valid (an external 3rd party backend which uses ascii
> chars for SlugField now) then we should go with that.
>
> On 5 November 2014 03:20, Michael Manfre  wrote:
>
>> Should the unicode validated field (either options) have a different
>> internal type for the sake of 3rd party database backends? I'm not sure if
>> any currently store SlugFIeld in an ascii char datatype and would need an
>> easy way to differentiate.
>>
>> Regards,
>> Michael Manfre
>>
>> On Tue, Nov 4, 2014 at 8:27 PM, Tim Graham  wrote:
>>
>>> I wanted to solicit feedback on the two approaches to supporting unicode
>>> in SlugField:
>>>
>>> 1. Added a unicode argument to models.SlugField and forms.SlugField.
>>> https://github.com/django/django/pull/1979
>>>
>>> 2. Added models.UnicodeSlugField and forms.UnicodeSlugField.
>>> https://github.com/django/django/pull/1987
>>>
>>> The patch author says, "On one hand, I like the new field approach
>>> because it gives us an easier upgrade path. On the other hand, it feels
>>> like I'm polluting django.db.models and django.forms with slightly
>>> different versions of something that's already there."
>>>
>>> Approach 1 does seem cleaner to me, but I'd be interested in hearing
>>> from those interested in this feature.
>>>
>>> Ticket: https://code.djangoproject.com/ticket/16501
>>>
>>> --
>>> 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/33e9747f-6ced-4710-9e59-ca128e065c5c%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/33e9747f-6ced-4710-9e59-ca128e065c5c%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>> 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/CAGdCwBv%3DfGD-DpG4w9Bd3_9FkcKiw_CYqhR8tJK8W1EC_zvQNg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CAGdCwBv%3DfGD-DpG4w9Bd3_9FkcKiw_CYqhR8tJK8W1EC_zvQNg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> 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/CAMwjO1H%2BCUXs%2B8_fQ_xiAMu%3DR%2BAxMNMmaTwaAEkavOmtAPcy8w%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMwjO1H%2BCUXs%2B8_fQ_xiAMu%3DR%2BAxMNMmaTwaAEkavOmtA

Re: Unicode SlugField design decision (#16501)

[Michael Manfre]

On Wed, Nov 5, 2014 at 7:53 PM, Shai Berger  wrote:

> On Wednesday 05 November 2014 17:29:20 Michael Manfre wrote:
> > We can change the internal type of SlugField for option 1 based upon
> > whether or not the field should be unicode. Whether or not an existing
> > backend stores SlugField in an ascii char datatype shouldn't dictate
> > whether we go with SlugField(unicode=True) or UnicodeSlugField(). Let me
> > rephrase the question as, Do we want to provide backends enough
> information
> > so that they can decide to store an ascii slug field in an ascii char
> field
> > (e.g. varchar) and a unicode slug field in a unicode char field (e.g
> > nvarchar)?
> >
>
> Could you please clarify the question? As far as I understand, schema
> editors
> get all the information anyway.
>

Constructing the schema is only one part of the process. The main bit I am
concerned about is how the ORM will translate the data. There are several
methods on DatabaseOperatoins that exist to act based upon a field's
internal type string. E.g. get_db_converters, field_cast_sql.

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

Re: Backend-specific lookups

[Michael Manfre]

Overriding get_db_prep_lookup seems like it would cause problems. Even if
were only registered when Oracle is in use, that would make multi-db with
Oracle as one of the backends problematic.

On Sat, Nov 15, 2014 at 5:46 PM, Josh Smeaton 
wrote:

> Clever. I don't mind this approach at all. Will the overriding of
> get_db_prep_lookup interfere with other implementations though?
>
> On Sunday, 16 November 2014 06:03:18 UTC+11, Shai Berger wrote:
>>
>> Hi,
>>
>> I'v been working on an old Oracle bug[1], and realized that a nice way to
>> solve it would be by overriding some builtin lookups with custom lookups
>> for
>> Oracle. However, I had some doubts about where to place the code:
>>
>> On the one hand, I could just add an "as_oracle()" to  the builtin lookup
>> classes. But I felt that would be cheating -- Oracle is in core, but what
>> would 3rd-party backends do?
>>
>> So I thought I would implement a custom lookup in the backend, which adds
>> an
>> "as_oracle", and register that when the backend is loaded. Loic commented
>> that
>> this is still problematic -- For example, I want to override "contains"
>> on
>> TextField's, so I would naturally inherit the built-in Contains lookup;
>> but if
>> a user has two backends which want to override "contains", they will be
>> in
>> conflict -- only one of them will get to install its handler.
>>
>> The solution I found was to use dynamic inheritance --  the backend
>> inherits
>> not the builtin Contains, but the registered lookup for "contains" on
>> TextField. This way, another backend can also add its own as_vendor()
>> method,
>> without any of us stepping on each other's feet.
>>
>> I've posted the initial example of this as a PR[2] for comments.
>>
>> This is related to some of the discussions about transforms (SQL
>> Functions)
>> that happened on the mailing list a couple of months ago[3], but the
>> topic of
>> backend-specific functions was not really the topic there, so I preferred
>> to
>> open a new discussion.
>>
>> Have fun,
>> Shai.
>>
>>
>> [1] https://code.djangoproject.com/ticket/11580
>> [2] https://github.com/django/django/pull/3544
>> [3] https://groups.google.com/d/msg/django-developers/
>> HggiPzwkono/dsnx3BuXpnkJ
>>
>  --
> 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/32571a2b-92cf-46fb-9373-a88772586349%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Template render performance

[Michael Manfre]

Thanks to the work Aymeric recently started, Django will have more options
with regards to templating. See his DEP on Multiple Template Engines.
https://myks.org/en/multiple-template-engines-for-django/dep/

Regarding changing the Django Template Language syntax for the sake of
performance improvements, backwards incompatible changes are not likely to
happen. There is a huge cost involved with forcing everyone to update their
templates. Ideas on improvements that are backwards compatible would be
welcomed by many!

Regards,
Michael Manfre


On Mon, Nov 17, 2014 at 9:17 PM,  wrote:

>  Hello,
>
> Mostly a question, but are there any work in progress to improve templates
> render performance? Times when having medium to big data and/or loops get
> excesively high, compared to jinja2 which sadly is not as easy to use as
> django native template language. I would really trade a feature or two in
> order to achieve better performance. For example, accessing variables from
> a dict, or even calling functions, all with the same syntax, I believe
> there's a huge overhead in there, and trading a xx.call for xx.call() is
> not such a big deal.
>
> What about a high performance option inside a template which trades
> flexibility for performance.
>
>   --
> 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/546aacd0.caa7340a.6c15.29a8%40mx.google.com
> <https://groups.google.com/d/msgid/django-developers/546aacd0.caa7340a.6c15.29a8%40mx.google.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAGdCwBtLaij4G%2BF63qG8jVpaPHyp3oFLKD%2B9Axx3nxjrUvs%3DDg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Configurable safety options for high performance Django systems

[Michael Manfre]

Django is a generic framework. Those who use it to implement functionality
are the ones who kill either the browser or their entire application.
Applications must be written to meet functional and performance
requirements of the project. When dealing with large tables, more effort is
certainly needed when using the Admin. E.g. write custom ModelAdmins or
admin filters that restrict the resultset size.

I don't think Django should automatically limit these queries.

Regards,
Michael Manfre

On Tue, Nov 18, 2014 at 7:58 AM, Rick van Hattem  wrote:

> Hi guys,
>
> As it is right now Django has the tendency to kill either your browser (if
> you're lucky) or the entire application server when confronted with a large
> database. For example, the admin always does counts for pagination and a
> count over a table with many rows (say, in the order of 100M) can really
> stall your app and database servers.
>
> In the past I've simply patched Django to include a few "security"
> features for cases like these so someone can't accidently kill the site by
> doing something silly, but I was wondering if it would be a good idea to
> include some of these configurable options in the core.
>
> Examples:
>  - If COUNT_LIMIT is set than wrap counts in a subquery and limit the
> results: SELECT COUNT(*) FROM (SELECT pk FROM table LIMIT )
>  - When someone does "if queryset" automatically limit it to a default
> slice size so someone doesn't accidently fetch all rows in the queryset.
>
> ~wolph
>
> --
> 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/9ec3e5e6-0681-4e5b-bb8e-c450ce38c96a%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/9ec3e5e6-0681-4e5b-bb8e-c450ce38c96a%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Configurable safety options for high performance Django systems

[Michael Manfre]

On Tue, Nov 18, 2014 at 7:42 PM, Josh Smeaton 
wrote:

> To me, "sane default" means django should not silently alter the query to
> provide a LIMIT when it is not asked for.
>
> I have also run into situations where doing a .count() or iterating a full
> table has broken the application, or put too much pressure on the database.
> Specifically with django bindings to javascript datatables. But I still
> wouldn't want artificial limiting on such queries.
>
> What *may* be useful, is to be able to apply queryset methods onto an
> already sliced queryset. That would allow users to implement
> queryset/manager methods that provide pre-sliced querysets to the rest of
> the code. The problem would be, what should happen in this case?
>
> Model.objects.all()[0:10].filter(field=True)
>
>
I think we'd need a non-slicing syntax to allow chaining of limit/offset.
E.g. Model.objects.all().set_slice(limit=10, offset=0).filter(field=True).
Changing the existing slicing output would be a major backwards
incompatible headache.


> Should the filter be logically/internally moved to before the limit? Or
> should the filter be applied to the result of the limit in an outer query?
> Traditionally, django applies mutations in succession, but this wouldn't be
> very useful the for the majority of operations that would occur "after" the
> slicing. We *could* say all slicing is "saved" and applied at the end, but
> we'd definitely run into issues with users reporting that filtering isn't
> working as they expect - after the slice.
>
> --
> 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/bef66ad3-c886-4106-8336-a2db13c340cc%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Configurable safety options for high performance Django systems

[Michael Manfre]

On Mon, Nov 24, 2014 at 3:32 PM, Christophe Pettus  wrote:

> In your particular case, where you have the relatively unusual situation
> that:
>
> 1. You have this problem, and,
> 2. You can't fix the code to solve this problem.
>
> ... you probably have the right answer is having a local patch for Django.
>

Alternatively, the same could be accomplished with a custom database
backend that enforces whatever limit value is desired. If I needed this
behavior, I'd probably tweak the query.low_mark and query.high_mark values
in SQLCompiler.as_sql before passing it along to the parent.

I think it's safe to say that this functionality is unlikely to find its
way in to Django, but if you have questions about the custom database
backend approach, feel free to contact me.

Regards,
Michael Manfre

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

Re: delegating our static file serving

[Michael Manfre]

Requiring fewer moving parts for small sites is definitely an improvement.
+1 to Collin's plan.

Regards,
Michael Manfre

On Fri, Dec 5, 2014 at 2:02 AM, Loïc Bistuer  wrote:

> I'm +1 on this plan, "native" support for wsgi.file_wrapper makes a lot of
> sense.
>
> --
> Loïc
>
> > On Dec 5, 2014, at 12:33 PM, Collin Anderson 
> wrote:
> >
> > Hi All,
> >
> > I'm pretty interested in getting secure and _somewhat_ efficient static
> file serving in Django.
> >
> > Quick history:
> > 2005 - Jacob commits #428: a "static pages" view.  Note that this view
> should only be used for testing!"
> > 2010 - Jannis adds staticfiles. Serving via django is considered
> "grossly inefficient and probably insecure".
> > 2011 - Graham Dumpleton adds wsgi.file_wrapper to Gunicorn.
> > 2012 - Aymeric adds StreamingHttpResponse and now files are read in
> chunks rather than reading the entire file into memory. (No longer grossly
> inefficient IMHO.)
> >
> > I propose:
> > - Deprecate the "show_indexes" parameter of static.serve() (unless
> people actually use it).
> > - Have people report security issues to secur...@djangoproject.com
> (like always)
> > - Audit the code and possibly add more security checks and tests.
> > - add wsgi.file_wrapper support to responses (5-line proof of concept:
> https://github.com/django/django/pull/3650 )
> > - support serving static files in production, but still recommend
> nginx/apache or a cdn for performance.
> > - make serving static files in production an opt-in, but put the view in
> project_template/project_name/urls.py
> >
> > I think it's a huge win for low-traffic sites or sites in the "just
> trying to deploy and get something live" phase. You can always optimize
> later by serving via nginx or cdn.
> > We already have the views, api, and logic around for finding and serving
> the correct files.
> > We can be just as efficient and secure as static/dj-static without
> needing to make people install and configure wsgi middleware to the
> application.
> > We could have staticfiles classes implement more complicated features
> like giving cache recommendations, and serving pre-gzipped files.
> >
> > Is this a good idea? I realize it's not totally thought through. I'm
> fine with waiting until 1.9 if needed.
> >
> > Collin
> >
> > On Saturday, November 29, 2014 6:07:05 PM UTC-5, Collin Anderson wrote:
> > Hi All,
> >
> > I think doing something here is really good idea. I'm happy with any of
> the solutions mentioned so far.
> >
> > My question is: what does static/dj-static do that our built-in code
> doesn't do? What makes it more secure? It seems to me we're only missing is
> wsgi.file_wrapper and maybe a few more security checks. Why don't we just
> make our own code secure and start supporting it?
> > Here's basic wsgi.file_wrapper support:
> https://github.com/django/django/pull/3650
> >
> > We could then, over time, start supporting more extensions ourselves:
> ranges, pre-gziped files, urls with never-changing content, etc. That way
> we get very, very deep django integration. It seems to me this is a piece
> that a web framework should be able to support itself.
> >
> > Collin
> >
> >
> > On Friday, November 28, 2014 9:15:03 AM UTC-5, Tim Graham wrote:
> > Berker has worked on integrating gunicorn with runserver so that we
> might be able to deprecate our own homegrown webserver. Windows support for
> gunicorn is supposedly coming soon which may actually make the idea
> feasible. This way we provide a more secure solution out of the box
> (anecdotes indicate that runserver is widely used in production despite our
> documentation warnings against doing so).
> >
> > On the pull request, Anssi had an idea to use dj-static to serve
> static/media files. My understanding is that we would basically integrate
> the code for dj-static into Django and then add a dependency on static. It
> could be an optional dependency since you might want to serve static files
> differently in production, but it would likely be more or less universally
> used in development. We could then say that django.views.static.serve (and
> its counterpart in staticfiles) is okay to use in production (and I guess
> people are already using them in production despite our warnings that they
> are not hardened for production use).
> >
> > What do you think of this plan?
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Dj

Re: uuid field short websafe representation

[Michael Manfre]

A non-standard, compressed unique value is not a UUID. Also, this forces
database backends to store the value in a string datatype and doesn't allow
taking advantage of uuid specific datatypes. E.g. Postgresql couldn't use
its uuid datatype. Any data can be made safe for any specific usage, e.g.
URLs, but there is no reason to enforce this requirement in all uses of the
data because not everyone will expose a UUID in a URL.

-1 from me.

Regards,
Michael Manfre

On Sat, Dec 6, 2014 at 11:31 AM, Radek Svarz  wrote:

> Hi, I am glad to see the UUID field coming to 1.8
>
> Bellow is how we do it now in 1.7.
>
> The advantages:
>
>  - it only uses 21 chars (instead of 32)
>
>  - chars are safe for URLs
>
>  - uuid is created when default is called
>
> I advocate to have the short websafe representation. What do you think?
>
> code:
>
>> def safe_uuid():
>> return uuid.uuid4().bytes.encode('base64').rstrip('=\n').replace('/',
>> '_')
>>
>
>
>> class UUIDField(CharField) :
>> """
>> UUIDField stored in 21 Chars
>> Example: uuid = UUIDField(primary_key=True, editable=False)
>> """
>> description = "UUIDField stored in 21 Chars"
>> def __init__(self, *args, **kwargs):
>> kwargs['max_length'] = kwargs.get('max_length', 22 )
>> kwargs['default'] = safe_uuid
>> CharField.__init__(self, *args, **kwargs)
>>
>> def deconstruct(self):
>> name, path, args, kwargs = super(UUIDField, self).deconstruct()
>> return name, path, args, kwargs
>
>
> Radek
>
>  --
> 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/1c29dfae-6483-465c-939e-f4319120781f%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/1c29dfae-6483-465c-939e-f4319120781f%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Experimental APIs DEP

[Michael Manfre]

On Sun, Dec 7, 2014 at 6:37 PM, Russell Keith-Magee  wrote:

>  * The corollary of this last point is that the release *before* a stable
> release can't have any experimental/provisional features.
>

 Does this mean that there should be no experimental/provisional features
in an LTS?

Regards,
Michael Manfre

-- 
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/CAGdCwButvr%2B6Fzj6-h4_U_p-RX_b4E%2BAjWeHTH-mUkqRvZ%3DBow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Optional schemes in URLValidator causes backward incompatible changes

[Michael Manfre]

Please open a ticket for this.

On Fri, Dec 12, 2014 at 9:11 AM, Bruno Ribeiro da Silva <
bruno.dev...@gmail.com> wrote:

> Hey everyone,
>
> I just found out that the new schemes option of URLValidator causes
> incompatible changes for people who were using custom regex to restrict
> schemes. Could somebody put a note in Django 1.7 backward incompatible
> changes documentation? Should I open a ticket for this?
>
> Thanks!
>
> --
> Bruno Ribeiro da Silva
> Python Dev and Homebrewer!
>
> --
> 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/CAE-2%3DJyajyKdvJ6-0oK%3D7NTt4fkpcOkFU8U9r9B8dQO9ob%3D7KA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Feature request: delegate more password related operations to auth backends (#23896)

[Michael Manfre]

I've used third party authentication backends, but your request seems a bit
odd to me. I think I'm being caught up on the some of the specifics without
enough context. Why can you not use a custom User that stores the backend
that created it (or last used for authentication) and overrides
set_password to delegate the password saving to the referenced
authentication backend? You would need to also create your own subclass of
ModelBackend that does the original User.set_password behavior. The only
scenario that I can think of where your implementation would get a bit more
complicated is if you wanted to support multiple active sessions using
different authentication backends for the same user object.

Regards,
Michael Manfre

On Sat, Dec 13, 2014 at 4:28 AM, Roman Akopov  wrote:
>
> Tim,
>
> It's not about the benefit, it's about the possibility. The one simply
> cannot use two external backends with support of password change because
> each backend will have to provide own User model. I understand your point,
> and I agree that some logic I suggest seems controversial, but current
> implementation of plugable authentication backends is technically incomplete,
> because password cannot be changed or reset, and ideologically broken,
> because full functionality cannot be correctly added even with a lot of
> code. Actually whole contrib.auth should be replaced to allow pluggable
> authentication backends to provide password change or password reset
> independently.
>
> Also, if you think it is good idea to force old behavior even if backend
> supports extended functionality, what stops us from introducing two boolean
> settings AUTHENTICATION_BACKEND_DELEGATE_PASSWORD_CHANGE and
> AUTHENTICATION_BACKEND_DELEGATE_PASSWORD_RESET which will be False by
> default? This will force old behavior while allowing to use extended
> backends if required.
>
> I want it to be clear, I'm not asking for specific functionality, I'm
> asking for extensibility. External authentication is complex subject by
> itself and fighting with incomplete Django extensibility interface does not
> make it simpler, but better extensibility interface does.
>
> Maybe, it will be wiser to discuss this feature request with people
> actually using external authentication, not core developers, to let them
> share their experience and maybe suggest better ways to implement this from
> the users/app developers point of view. Maybe this feature is desired one,
> but I'm just first who asked or maybe nobody actually needs it and I;m just
> Django-pervert. I can talk about my end users only, and about theirs user
> experience, you have no externally authenticated users at all. If we've
> done with technical side, I mean it seems clear what should be changed at
> source code level, and if only specific behavior logic is to be discussed,
> maybe it is better to discuss this non-core developer question with wider
> audience. What do you think?
>
>
>
> On Saturday, December 13, 2014 3:19:26 AM UTC+4, Tim Graham wrote:
>>
>> I haven't used external authentication backends for any projects, but I
>> still think the concept of dynamically changing how the password change
>> form/views work based on which backend you authenticated with is too much
>> complexity. This scheme feels very brittle and I'm not sure that making
>> this change in Django offers much benefit (in reduced code, for example) in
>> the end.
>>
>> On Thursday, December 11, 2014 2:05:22 PM UTC-5, Roman Akopov wrote:
>>>
>>> I've researched a little more, and looks like there is
>>> BACKEND_SESSION_KEY so it is possible to annotate user with backend on
>>> subsequent requests.
>>> https://github.com/django/django/blob/master/django/
>>> contrib/auth/__init__.py#L169
>>> Look like it should be a one line fix for this like
>>> user.backend = backend
>>> I think this will not break any existing code.
>>>
>>> At non-request situations for non-authenticated User model, i.e.
>>> instantiated from database, or just created and saved, we can simply
>>> fallback to old behavior. Actually, I think this is correct, because a user
>>> can have valid credentials in various backends simultaneously. Imagine we
>>> have three backends: Model, LDAP, SMTP. So if you authenticate with
>>> credentials valid for SMTP backend, you can't change password because SMTP
>>> does not support this at all. It should be something like methods throwing
>>> NotImplementedError. If you authenticate with credentials valid for LDAP
>>> backend you can change password and that change will be performed against
>>> LDAP

Re: Settings: lists or tuples?

[Michael Manfre]

+1 for lists.

On Wed, Dec 17, 2014 at 3:54 PM, Carl Meyer  wrote:
>
> On 12/17/2014 01:48 PM, Aymeric Augustin wrote:
> > I’m about to introduce a new setting that is a sequence of things,
> TEMPLATES, and I have to decide whether it will be a tuple of a list.
> >
> > Unfortunately Django is very inconsistent in the type of settings. In
> global_settings.py:
> >
> > - 22 settings are tuples
> >   - 10 are empty, 12 aren't
> >   - 12 are referred to as “lists” in code comments, 1 as “tuple”
> > - 6 settings are lists
> >   - all of them are empty
> >
> > Even the tutorial is inconsistent. The first two settings described are:
> >
> > - INSTALLED_APPS: example is a tuple
> > - TEMPLATE_DIRS: example is a list
> >
> > It would be nice to standardize on tuples or lists — at least for new
> code if it’s undesirable to change the existing code.
> >
> > This is purely a matter of consistency and aesthetics. Using a tuple or
> a list never makes any difference in the code.
> >
> > While lists are less common than tuples currently, I prefer them for two
> reasons:
> >
> > 1) All these settings are sequences of similar things. Such values are
> best represented with lists, unless they have to be immutable, in which
> case a tuple can be used. (tuples are both “namedtuples without names” and
> “immutable lists” in Python.)
> >
> > 2) Lists aren’t prone to the “missing comma in single-item tuple”
> problem which bites beginners and experienced pythonistas alike. Django
> even has code to defend against this mistake for a handful of settings.
> Search for “tuple_settings” in the source.
>
> I agree with your preference for lists, for the same two reasons.
>
> > Surprisingly, it seems that there isn’t a backwards compatibility
> problem with changing the type to lists, as the following pattern still
> works:
> >
> > # myproject/settings.py
> > from django.conf.global_settings import FILE_UPLOAD_HANDLERS
> > FILE_UPLOAD_HANDLERS += ('myproject.uploadhandler.FooBarUploadHandler',)
> >
> > Proof:
> >
>  foo = ['abc']
>  foo += ('def',)
>  foo
> > ['abc', ‘def’]
> >
> > I can’t think of another circumstance it which the type of the default
> value will make a difference.
> >
> > So… can we normalize the code and satisfy my OCD? Or should I just stop
> caring and move on? ;-)
>
> Unfortunately `__iadd__` and `__add__` do not have the same behavior here:
>
> >>> foo = ['abc']
> >>> foo = foo + ('def',)
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: can only concatenate list (not "tuple") to list
>
> So I think there is a backwards-compatibility issue.
>
> Personally, I would love to decide to just bite this bullet and
> normalize to lists, but I think it would need to be marked as a
> backwards-incompatibility in the release notes, and it would certainly
> bite people.
>
> Carl
>
> --
> 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/5491ED93.2080506%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Multiple template engines for Django - week 12

[Michael Manfre]

If I'm understanding your post correctly, any potential performance
improvement that a special cased select_template would have would likely be
negated by caching. Have you observed, or do you expect to see any
significant performance hits to the test suite, which doesn't cache as
intensely as live sites?

Regards,
Michael Manfre

On Sat, Dec 27, 2014 at 5:59 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> My twelfth update is online:
> https://myks.org/en/multiple-template-engines-for-django/#2014-12-28
>
> It comes with a question — should I drop `select_template` from the
> backend API? I think I should. Follow the link above for details.
>
> Looking forward to your feedback,
>
> --
> 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/CAGdCwBsUd4B%3D7NkKh6oEaaqwFNvCCcupRsOMFcEfRfMoUsH0vg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multiple template engines for Django - week 12

[Michael Manfre]

Thanks for the explanation. It makes sense to remove select_template.

Regards,
Michael Manfre

On Sun, Dec 28, 2014 at 3:53 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hi Michael,
>
> > On 28 déc. 2014, at 07:12, Michael Manfre  wrote:
> >
> > If I'm understanding your post correctly, any potential performance
> improvement that a special cased select_template would have would likely be
> negated by caching.
>
> Sorry, I didn’t explain sufficiently clearly. My reasoning was:
>
> 1) Is there any situation where I can call a backend's select_template?
> Yes, when only one template engine is configured.
> 2) Does this have any advantages? Unclear, it may allow some performance
> optimizations at the backend level but that's completely theoretical.
> 3) Does that make it worth keeping select_template? Probably not.
>
> > Have you observed, or do you expect to see any significant performance
> hits to the test suite, which doesn't cache as intensely as live sites?
>
> No, I don’t expect to see a measurable impact on the test suite’s run
> time, because the current code and the new code will do roughly the same
> amont of work and neither optimizes anything.
>
> --
> 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/05BAC9A8-41C3-4FD8-88F2-531E933C517C%40polytechnique.org
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAGdCwBtv7jkA-y-c3OcCs-hUbRfwi9y66v_JpHSbEFxCeY-1Ag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multiple template engines for Django - week 13

[Michael Manfre]

+1 to delaying the freeze to get this feature fully in place, especially
since 1.8 will be an LTS release. Is there precedent to doing a freeze with
an exemption for an in progress feature? If so, that is another option to
an outright extension.

Regards,
Michael Manfre

On Sat, Jan 3, 2015 at 8:44 PM, Jeremy Dunck  wrote:

> If getting proper support for other template backends would only delay the
> 1.8 release timeline by a couple weeks, I think that is preferable to a
> generalized 1.8 backend which only include DTL until 1.9.
>
> What do others think?
>
>
> On Sat, Jan 3, 2015 at 3:23 PM, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> Hello,
>>
>> Here’s the thirteenth update (good thing I learnt all these ordinals when
>> I was a kid!)
>> https://myks.org/fr/multiple-template-engines-for-django/#2015-01-04
>>
>> At this point my main concern is the 1.8 feature freeze scheduled in one
>> week.
>> Dealing properly with some of the items I listed in my report for week 11
>> may
>> require changes falling in the "new features” bucket and therefore being
>> postponed to Django 1.9. At worst, I’ll have to document that some
>> features
>> only work with the Django template language in Django 1.8. That’s sad but
>> not
>> worth delaying the entire project until early 2016.
>>
>> --
>> Aymeric.
>>
>>
>>
>> > On 27 déc. 2014, at 23:59, Aymeric Augustin <
>> aymeric.augus...@polytechnique.org> wrote:
>> >
>> > Hello,
>> >
>> > My twelfth update is online:
>> > https://myks.org/en/multiple-template-engines-for-django/#2014-12-28
>> >
>> > It comes with a question — should I drop `select_template` from the
>> backend API? I think I should. Follow the link above for details.
>> >
>> > Looking forward to your feedback,
>> >
>> > --
>> > Aymeric.
>> >
>> >
>> >
>> >> On 20 déc. 2014, at 23:57, Aymeric Augustin <
>> aymeric.augus...@polytechnique.org> wrote:
>> >>
>> >> Hello,
>> >>
>> >> I haven’t written to this mailing-list for three weeks because nothing
>> warranted your immediate attention.
>> >>
>> >> Now the code is in reasonably good shape. Feel free to have a look:
>> >> https://github.com/aaugustin/django/commits/multiple-template-engines
>> >>
>> >> I plan to merge this branch within a few days.
>> >>
>> >> Updates for weeks 9 to 11 are available at the usual location:
>> >> https://github.com/aaugustin/django/commits/multiple-template-engines
>> >>
>> >> --
>> >> Aymeric.
>> >>
>> >>
>> >>
>> >>> On 30 nov. 2014, at 10:37, Aymeric Augustin <
>> aymeric.augus...@polytechnique.org> wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> Here’s my eight update — this is getting repetitive :-)
>> >>> https://myks.org/en/multiple-template-engines-for-django/#2014-11-30
>> >>>
>> >>> --
>> >>> Aymeric.
>> >>>
>> >>>
>> >>>
>> >>>> On 23 nov. 2014, at 00:02, Aymeric Augustin <
>> aymeric.augus...@polytechnique.org> wrote:
>> >>>>
>> >>>> Hello,
>> >>>>
>> >>>> I published my seventh update:
>> >>>> https://myks.org/en/multiple-template-engines-for-django/#2014-11-23
>> >>>>
>> >>>> I have another pull request ready for review:
>> >>>> https://github.com/django/django/pull/3605
>> >>>>
>> >>>> Let me know if you have any questions!
>> >>>>
>> >>>> --
>> >>>> Aymeric.
>> >>>>
>> >>>>
>> >>>>
>> >>>>> On 16 nov. 2014, at 09:19, Aymeric Augustin <
>> aymeric.augus...@polytechnique.org> wrote:
>> >>>>>
>> >>>>> Hello,
>> >>>>>
>> >>>>> Here’s my sixth update:
>> >>>>>
>> https://myks.org/en/multiple-template-engines-for-django/#2014-11-16
>> >>>>>
>> >>>>> I have a first pull request ready for review:
>> >>>>> https://github.com/django/django/pull/3555
>> >>>>>
>> >>>>> Whenever possible, I’

Re: documenting changes to the database backend API

[Michael Manfre]

For completeness, I'm Michael Manfre and have been the maintainer of
Django-mssql [1] for the last 6+ years. Future releases of Django-mssql
will officially support a single version of Django. Support for legacy
versions of Django will be maintained if it requires little effort.

Work on Django 1.8 support has started and I'll update the release notes as
I encounter issues.

Regards,
Michael

[1] https://bitbucket.org/Manfre/django-mssql/
On Jan 9, 2015 12:00 PM, "Tim Graham"  wrote:

> To authors of third-party database backends,
>
> We'd like to start documenting changes to the database backend API [1],
> but we need some help with this.
>
> First, please introduce yourself and which backend you maintain so we know
> of your existence.
>
> Second, we'd like to know if you attempt to support multiple versions of
> Django in a particular release of your backend? This will help us to decide
> whether or not try to document the changes in a backwards and forwards
> compatible way.
>
> Third, could you try updating your backend to 1.8 and let us know what
> problems you run into so we know what documentation to add?
>
> The section of the release notes that will be expanded with details is:
> https://docs.djangoproject.com/en/dev/releases/1.8/#database-backend-api
>
> Thank-you!
>
> [1] https://code.djangoproject.com/ticket/24106
>
> --
> 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/a9c2aefc-f6f0-46db-804a-3608d033017c%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/a9c2aefc-f6f0-46db-804a-3608d033017c%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Settings: lists or tuples?

[Michael Manfre]

The situation you described was definitely a learning experience for your
company. Your strong opinion in favor of tuples is also noted.

For the various reasons stated in this thread, I'm still +1 for lists.

Regards,
Michael Manfre

On Mon, Jan 19, 2015 at 3:13 PM, Andreas Kahnert  wrote:

> I advertise that strongly against lists, because we actually had that kind
> of issue in our company.
> One colleague created a list with phrases for some verbose logging in the
> settings.py. In the view function he promoted this list together with the
> actual data, also a list which is used for storing the data afterwards, to
> another function. The other function was implemented by another colleague,
> he was aware that he should not modify the second list for not corrupting
> the data to be safed. So he appended the data components to the first list
> zipped it to an dict and called the logging function. The result was that
> every log entry contained all data from previous calls and the server loked
> down very quick. It took them a day to debug this.
>
> --
> 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/64cb1e61-8eb2-4459-ac77-6fa1c3837c98%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/64cb1e61-8eb2-4459-ac77-6fa1c3837c98%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Making the test suite run faster

[Michael Manfre]

Anything to make the test suite faster is a worthwhile effort. The speed up
will be even better for those of us with slower dev systems. Getting the
speed boost for in memory sqlite is a good start and Django is much more
than an ORM. It'll take work to improve the database isolation for the test
suite, but that is something that should probably happen regardless of
parallelization.

I'm imagining database backends being able to control whether or not they
support parallelization and if each process needs its own database.

Regards,
Michael Manfre

On Fri, Feb 6, 2015 at 11:05 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> As the test suite is growing, it’s getting slower. I’ve tried to make it
> faster by running tests in parallel.
>
> The current state of my experiment is here:
> https://github.com/django/django/pull/4063
>
> I’m distributing the tests to workers with the multiprocessing module.
> While the idea is simple, the unittest APIs make its implementation painful.
>
> ** Results **
>
> Without the patch:
>
> Ran 9016 tests in 350.610s
> ./runtests.py  355,86s user 20,48s system 92% cpu 6:48,23 total
>
> With the patch
>
> Ran 9016 tests in 125.778s
> ./runtests.py --parallel  512,31s user 29,92s system 300% cpu 3:00,73 total
>
> Since it takes almost one minute to create databases, parallelization
> makes the execution of tests go from 6 minutes to 2 minutes.
>
> This isn’t bad, but the x3 speedup is a bit disappointing given that I
> have 4 physical / 8 logical cores. Perhaps the IPC is expensive.
>
> Does anyone have insights about scaling with multiprocessing?
>
> ** Limitations **
>
> This technique works well with in-memory SQLite databases. Each process
> gets its own copy of the database in its memory space.
>
> It fails with on-disk SQLite databases. SQLite can’t cope with this level
> of concurrency. It timeouts while attempting to lock the database.
>
> It fails with PostgreSQL (and, I assume, other databases) because tests
> collide, for instance when they attempt to load the same fixture.
>
> ** Next steps **
>
> At this point, the patch improves the common use case of running
> `./runtests.py` locally to check a database-independent change, and little
> else.
>
> Do you think it would be useful to include it in Django anyway? Do you
> have concerns about the implementation? Charitably, I’ll say that “it
> works”…
>
> Releasing it separately as a custom test runner may be more appropriate.
>
> What do you think?
>
> --
> 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/639C2955-7AAB-4BC6-940D-EA69F7F51280%40polytechnique.org
> <https://groups.google.com/d/msgid/django-developers/639C2955-7AAB-4BC6-940D-EA69F7F51280%40polytechnique.org?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAGdCwBujE%2BJSs%2BiupVxWCcTKV5VcT7%3DmZw71DnaVODQDZ%3DqxuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding missing aggregate functions to contrib.postgres ?

[Michael Manfre]

It's reasonable to support backend specific aggregate functions. The
database backend API contains
BaseDatabaseOperations.check_expression_support for this exact reason. Feel
free to create the ticket.

Regards,
Michael Manfre

On Sat, Feb 7, 2015 at 9:00 AM, Andriy Sokolovskiy (coldmind) <
sokand...@yandex.ru> wrote:

> So, since django has contrib.postgres, maybe it would be reasonable to add
> postgres-specific aggregate functions to this module?
> If it is good idea, I'm gonna create ticket and implement this.
>
> --
> 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/2d3b2bd2-3bce-4e40-8383-ef5ca328bc26%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/2d3b2bd2-3bce-4e40-8383-ef5ca328bc26%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAGdCwBtuSSi7x10-0pBLae1PRGA-ULmm6sxMAnzYqxdZLv7Kuw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: A general way to batch SQL queries in Django

[Michael Manfre]

Stored procedures, at least with MSSQL, provide another way of returning
multiple result sets with a single SQL statement. The queries will be
parsed and executed faster due to stored procedures being parsed and
compiled when created, instead of when executed. A stored procedure will
also allow you to get more complex results with a few simple queries,
instead of a single complex query.

Using stored procedures adds complexity to a Django project and should be
used sparingly. From my personal experience, the extra server resources to
have more instances running to service requests is usually better than
having the extra complexity of using stored procedures in a Django project.

Regards,
Michael Manfre

On Fri, Feb 27, 2015 at 2:46 PM, Tom Evans  wrote:

> On Fri, Feb 27, 2015 at 3:19 PM, aRkadeFR  wrote:
> > What do you mean by a single roundtrip?
>
> He means asking the database server to consider multiple queries
> (concurrently?), and return data once all of them are available. In
> pseudo code:
>
> people, jobs, cities = DB.fetch_multi(
> Person.objects.all(),
> Job.objects.all(),
> City.objects.all())
>
> MySQL's C API supports executing multiple SQL statements in a single
> round trip, the data sets are made available in turn to the client API
>
> http://dev.mysql.com/doc/refman/5.7/en/c-api-multiple-queries.html
>
> however, each statement is executed in turn, not concurrently, so the
> only speed up you would have is that there is only one query to parse,
> and a few small packets less sent to the database server... The
> database connection is not torn down between requests to the database.
>
> The only way I could see it having any non-marginal effect is if you
> have high latency to your database server. But then you have a lot of
> problems.
>
> Cheers
>
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAFHbX1%2BMgfwHL%3DL8hjgRMyf%2B2-Rap9L01PF9cxERFqU6c8uHdA%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAGdCwBuxXXSTrB68YFQ503RAfxH1z_BBxpytLk-75gwuGs3-zw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Composite fields

[Michael Manfre]

As the others have already stated, patience is required if you want
meaningful feedback.

Have you thought about how CompositeFields and SubFields will interact with
migrations?

Regards,
Michael Manfre

On Wed, Mar 4, 2015 at 8:16 AM, Thomas Stephenson  wrote:

> Considering the past two proposals I've made here, I doubt I'll get more
> than an echo chamber effect on this one.
>
> For the past week or so I've spent a bit of time on a feature I've always
> wanted to see land in django -- composite fields. The tickets have been
> open in the bug tracker for quite some time (and there's a few related
> ones, such as multi-column primary keys that can all be killed with the one
> stone).
>
> The work is available on this branch of my fork of django
> <https://github.com/ovangle/django/tree/composite_fields> for the moment
> -- I haven't opened up a PR yet because there's still some features that
> are still to be implemented that will be explained below, but I want to
> give everybody a chance to tell me where I can stick it before I spend
> *too* much time on it.
>
> So, without further ado, the proposal.
>
>
> Composite Fields - Implemented
>
> A composite field is an encapsulation of the functionality of a subset of
> fields on a model. Composite fields can be defined in one of two ways:
>
> 1. Statically declared composite fields
>
> A statically declared composite field is defined in the same way a django
> model is defined. There are two customisable transformation functions,
> CompositeField.value_to_dict(self, value) and
> CompositeField.value_from_dict(self, value) which can be used to associate
> the field with a python object.
>
> All the serialization functions are implemented via the implementations of
> the subfields.
>
> For example,
>
> class MoneyField(models.CompositeField):
>currency_code = models.CharacterField(max_length=3)
>amount = models.DecimalField(max_digits=16, decimal_digits=4)
>
>## Overriding __init__ can be used to pass field parameters to the
> subfields
>
>def value_from_dict(self, value):
>if value is None:
>   return None
>return Money(**value)
>
>def value_to_dict(self, value):
>   if value is None:
>  return None
>   return {attr: getattr(value, attr) for attr in ('currency_code',
> 'amount')}
>
> 2. Inline composite fields.
>
> An inline composite field is declared at the field definition site on the
> body of a model, by providing the subfields as the 'fields' argument of the
> CompositeField constructor. There are no transformation parameters
> available to override when declaring a composite field in this fashion --
> the value of the field is always available as a python `dict` as an
> attribute on the MyModel
>
> class MyModel(models.Model):
> id = models.CompositeField(fields = [
>('a', models.IntegerField()),
>('b', models.CharField(max_length=30)
> ], primary_key=True)
>
> This method for defining composite fields has a few drawbacks, but can be
> useful if the only reason to add the composite field to the model was to
> implement a unique_together or index_together constraint *
>
> * Although it's still possible to do that directly on class Meta.
>
> 3. Null
>
> Setting the value of a multi-column field to NULL is different than
> setting any of the individual subfields to NULL. But there are cases (e.g.
> Money) where we would like to be able to set `null=True` on a composite
> field, but still retain 'NOT NULL' constraints on each of the subfield
> columns.
>
> To solve this problem, every table which implements a CompositeField will
> also add an implicit (semi-hidden) `isnull` subfield on the attribute,
> which keeps track of whether it is the value of the composite field that is
> null, or any of the particular subfields.
>
> 3. Querying.
>
> The syntax for querying over the subfields of a composite field will be
> familiar to anyone who has queried over a relationship attribute in django.
>
> model.objects.filter(price__currency_code='USD',
> price__amount__lt=Decimal('50.00')).all()
>
> In addition, composite fields can be queried via EXACT and IN lookups. It
> is possible to implement custom lookups for specific statically defined
> fields, but not recommended and not part of the official API.
>
> 4. Restrictions
>
> The following restrictions are currently imposed on the use of composite
> fields. None of these are restrictions that can't be worked around in
> future extensions, but they're restrictions which consider

Re: Composite fields

[Michael Manfre]

 which I'd like to preserve for as long as
> possible to keep the initial implementation and API simple).
>
> The point is (no pun intended) that I can't really think of a good way to
> map a python None to the values of a composite field _without_ the extra
> implicit column. It's not the nicest solution in the world, but it works.
>

I'd argue that not being able to have a hierarchy of Composite fields is a
feature.

Regards,
Michael Manfre

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

Re: Composite fields

[Michael Manfre]

-1 on silently changing the field definition. At best this would result in
an unnecessary migration when the error is discovered. Django should error
out with a message that the composite field definition is invalid.

Regards,
Michael Manfre

On Sun, Mar 8, 2015 at 12:29 PM, Thomas Stephenson 
wrote:

> ps. There's a third option which I just thought of:
>
> class Point(...):
>x = models.IntegerField()
>y = models.IntegerField()
>z = models.IntegerField(null=True)
>
>def __init__(self, null=False, **kwargs):
>if null:
>  x.null = y.null = True
>   super(Point, self).__init__(**kwargs)
>
>def deconstruct(self):
>   # etc.
>
> The framework could handle this and mandate "If a composite field has
> `null=True`, then all subfields are forced into the state `null=True`
> etc.", applying the `__init__` and `deconstruct` stuff itself.
>
> Yep -- I like this solution better.
>
> Thomas
>
>
> On 9 March 2015 at 03:12, Thomas Stephenson  wrote:
>
>> @Aymeric
>>
>> Here's why I think the `isnull` column is necessary.
>>
>> Say you've got a custom field implementation:
>>
>> class Point(models.CompositeField):
>>  x = models.IntegerField()
>>  y = models.IntegerField()
>>  # etc.
>>
>> and you use this to define a coordinate system to locate objects in your
>> models. You justify that whenever you provide a point, you'll want both an
>> x and y coordinate, so you make both of the subfields non-null.
>>
>> But then you come across a model which may or may not have a location.
>> You'd like to say
>>
>> class MaybeLocatable(models.Model):
>>point = Point(null=True)
>>
>> but you can't, because both of your subfields are non-nullable, so you
>> define a nonsensical condition to apply to your Point
>> "If I don't have an x-coordinate, then the point value should be
>> considered null"
>> so you update the Point field appropriately (and apply all the necessary
>> migrations).
>>
>> You then want to query for all `MaybeLocatable` objects that are
>> considered null. You can query for point__isnull=True (which is supposed to
>> be supported). How does one define the lookup transformation for that?
>>
>> If there was an implicit 'isnull' column added, then the lookup
>> transformation for both `point__isnull=True` and `point=None` become a
>> lookup for the database column `point__isnull = True`. If you don't add
>> that extra column, how does the framework what transform to make? It could
>> query for both `point__x__isnull` and `point__y__isnull`, but that wouldn't
>> match the semantics for the column.
>>
>> And you also can't say "well, look at the field definition and if a
>> column is nullable, then use it as a marker, because what if you instead
>> had:
>>
>> class Point(models.CompositeField):
>>x = models.IntegerField(null=True)
>>y = models.IntegerField()
>>z = models.IntegerField(null=True)
>>
>> as your original class? `x` could still be used as the "marker" column,
>> but any transformation you'd make with the above rule. So the framework
>> can't actually define a workable `isnull` query (or an 'exact' query when
>> the python value is `None`). The whole issue of the "marker" column is
>> fraught anyway, because it breaks all the NOT NULL constraints on other
>> columns anyway.
>>
>>
>>
>> So instead of all that, the user decides that they're going to solve the
>> problem with
>>
>> class MaybeLocation(models.Model):
>>has_point = models.BooleanField()
>>point = models.Point(default=Point(0,0))
>>
>> which is exactly the same solution as including the implicit `isnull`
>> field when the field is created with `null=True`, except the user has to do
>> it explicitly, and implement the logic surrounding the definition
>> themselves.
>>
>> They also can't define a new CompositeField like
>>
>> class MaybePoint(...):
>>has_point = models.BooleanField()
>>point = Point()
>>
>> because of the inheritance limitations (which I might have to lift in the
>> medium-long term anyway, but which I'd like to preserve for as long as
>> possible to keep the initial implementation and API simple).
>>
>> The point is (no pun intended) that I can't really think of a good way to
>> map a python None to the values of a composite field _without_ the extr

Re: inspectdb database defaults

[Michael Manfre]

I agree with Tim.

I would support refactoring inspectdb so that it would be easier for anyone
to subclass the command and add additional logic to the introspection
process. Alternatively, moving much of the logic out to a function that
returns a JSON representation of the database that inspectdb uses to write
the model data.

Regards,
Michael Manfre

On Tue, Mar 10, 2015 at 11:56 AM, Collin Anderson 
wrote:

> Hi All,
>
> We recently added database introspection of defaults for purposes of
> testing migrations.
>
>
> https://github.com/django/django/commit/75303b01a9cc900eebf1f27ba0bc6508334242fc
>
> I would find it useful to have inspectdb attempt to use those defaults
> when generating models. (My use case is running inspectdb on a WordPress
> database which has a bunch of database defaults.)
>
> Rough proof of concept: https://github.com/django/django/pull/4030
>
> Though Tim says: "Translating database level defaults into model field
> defaults isn't functionally equivalent and given that Django doesn't
> translate the model field default option into a database level default, I
> think it would be inconsistent to do a conversion in the other direction."
>
> Collin
>
>  --
> 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/11972cea-2565-4940-abe6-8cdec8f40a1e%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/11972cea-2565-4940-abe6-8cdec8f40a1e%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAGdCwBtPJ30Rv5Bx2h-Thy0rqaG%3D7AC%3DGROWhn26rRPoNBhBmQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Michael Manfre]

On Sat, Apr 4, 2015 at 12:56 PM, Thomas Tanner  wrote:

> I think rare LTS releases and frequent (6month) incremental upgrades are
> a good compromise.
> Third-party packages should support LTS releases and at least the latest
> Django version. They may drop support for earlier non-LTS releases.
> Either you stick with the LTS release or you go with the cutting edge
> with all dependencies.
>

I'm not advocating for or against more frequent releases, but trying to
impose a support policy upon 3rd party packages is not going to work. It
would great if they support whatever versions of Django are still
supported, but sometimes that takes more time/effort than the maintainer is
willing to devote.

The number or frequency of releases doesn't matter as much as the content
of the releases. Depending on the app, some Django versions are harder to
support at the same time. The back-to-back major changes to the Datatbase
API forced django-mssql to only support a single Django version with each
release. After that change, I was less inclined to backport fixes and even
stopped testing against Django 1.4 well before it was out of support.



> Advantages of release early, release often are that new features have
> more time to mature before a LTS release, you don't have to risk using
> the unstable HEAD for new features, and more feedback from users.
>
> On 04.04.15 14:30, Tim Graham wrote:
> > Now that Django 1.8 is released, I wanted to bump this thread for
> > discussion so we can hopefully ratify this schedule or modify it based
> > on feedback. In particular, I heard a concern that a six month release
> > schedule may be too often for the community. On the other hand, I think
> > smaller releases would make incremental upgrades easier.
> >
> > One difficulty could be if third-party packages try to support every
> > version since the last LTS (this seemed to be common with 1.4). A 6
> > month release schedule would mean 5 versions of Django until the next
> > LTS, instead of 3 as we had since 1.4, so more `if DJANGO_X_Y`
> > conditionals. One idea is that third-party packages could declare their
> > own "LTS" versions (if needed) and drop support for older versions more
> > freely in future development.
>
> --
> 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/552017D7.6020907%40gmx.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAGdCwBvxx%3DVKUscGQV1v%3DezeRkJVY4VJzDBZd9OaJ5SF9951oA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Must a Django Database Support Migrations?

[Michael Manfre]

On Sun, Apr 26, 2015 at 8:33 PM, Marcin Nowak 
wrote:

> Hi.
>
> Before v1.7 there were no migrations and Django was quite useful (for
> example with South as an 3rd party app). What happened then?
>
> I think that migrations can be decoupled from core and you just don't want
> to do this for some unknown reason.
> I'll prepare a pull request if it will not be dropped because of some kind
> of ethos.
>

As the person who started this thread over a year ago with the motivation
of making migrations support optional, I can definitively say that
migrations will not be removed from Django. Any pull request attempting to
do so will be declined. There are certain portions of Django that can (and
likely should) be decoupled, the database API (including migrations) is not
one of those pieces. One of the many reasons for it to remain in core is
that it's useful being able to modify the models that ship with Django.
E.g. increasing the size of user name field.

Regards,
Michael Manfre

-- 
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/CAGdCwBvKVPhERYzSpP9AZ6%2Bd83ehiZhC%2BUqMXf9SRQzw_W%2B5%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Guessable entry points

[Michael Manfre]

I like the alias.

On Fri, May 1, 2015 at 5:58 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> `python -m django` as a alias for `django-admin` sounds good.
>
> --
> Aymeric.
>
>
>
> On 30 avr. 2015, at 19:15, Ryan Hiebert  wrote:
>
> https://github.com/django/django/pull/4588
>
> I this PR I suggest to add a `django` entry point that is identical to
> `django-admin`, and a `__main__.py` that also is a mirror of `django-admin`.
>
> There’s also related discussion at
> https://github.com/django/django/pull/3861
>
> There’s precedent for using these as the primary methods of use all over
> the place. Flask, in particular, uses both the `flask` command as well as
> `python -m flask`. Celery also uses the `celery` command as well as `python
> -m celery`.
>
>
> I see value in adding these endpoints that are more easily guessable.
> However, there’s a cost too, the cost of having more than one way to do it.
> We already have `django-admin` and `django-admin.py`, would adding these
> obvious entry points give too many options?
>
> Ryan
>
> --
> 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/90DC7B87-35F5-4B77-93EA-7734DA31EA86%40ryanhiebert.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>  --
> 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/37733725-6295-48F4-98D1-BC82978EE570%40polytechnique.org
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

-- 
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/CAGdCwBtZbmwE1hU-5knGR-OPO23Y35wZ5cV2ygDOK7aaPTUt1w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: New function to sort words with accents.

[Michael Manfre]

Hi Paulo,

Your issue can be solved by modifying the database collation or with
application code (E.g. SlugField). The django-developer mailing is for
discussion of the Django framework. The django-users mailing list is the
appropriate place to start/continue a discussion about how you can resolve
this issue.

Regards,
Michael Manfre

On Tue, May 5, 2015 at 8:52 PM, Paulo Maciel 
wrote:

> I am returning the query Something.objects.all().order_by(Lower('name'))
> but the order is not respecting names that start with accent, causing these
> results appear at the end of ordering. We need a function to ignore accents
> and order correctly names with accents, as well as function Lower treats
> the results.
>
> *Currently:*
>
> arroz
> baleia
> dado
> limão
> xerox
> água
> ótimo
>
> *As it should be:*
>
> água
> arroz
> baleia
> dado
> limão
> ótimo
> xerox
>
>
> We need a function like it to fix the problem:
> Person.objects.all().order_by(Unaccent('name'))
>
> This is a priority issue because it affects thousands of Brazilians and
> other nationalities who use Portuguese.
>
>
>  --
> 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/27620089-a89e-4e13-9576-637e37395754%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/27620089-a89e-4e13-9576-637e37395754%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: No way to optimize batch deletion

[Michael Manfre]

A pre/post batch_delete signal would be useful for the usage you describe.
There would likely be confusion with its usage because unlike post_delete,
the batch_delete signals would not be able to provide actual records. The
best it could do would be to provide the queryset and the deletion count on
the post. The topic of batch deletion signaling has come up before, but I
don't remember the outcome (or whether it was on here or IRC). I'll try to
find it and report back when I get to a more capable device.

Regards,
Michael Manfre

On Thu, May 7, 2015 at 7:36 PM, Antoine Catton 
wrote:

> Hello,
>
> django-treebeard [1] has an optimized batch deletion for its models. [2]
>
> The main reason is because post_delete signals are called for each
> objects. And custom deletion in treebeard can be done in batch.
>
> I was reading Django's code [3] and it looks like there's no way to hook
> into _raw_delete() or DeleteQuery.delete_batch().
>
> The only way is to hook into signals.post_delete.
>
> This causes problems if we have something like this:
>
>   class A(treebeard.MP_Tree):
>   b = ForeignKey('B')
>
>   class B(models.Model):
>   a = IntegerField()
>
> If we run:
>   B.objects.filter(expression).delete()
> Because Treebeard is overriding A.objects.delete(), the custom delete()
> will never be called on the tree, and the tree will be inconsistent.
>
> One solution I can think of, would be to add a pre/post batch_delete
> signal. But I'm open to any other solution.
>
>
> [1] <http://code.tabo.pe/django-treebeard/src>
> [2] <
> http://code.tabo.pe/django-treebeard/src/04ca69b7daf6390bb2130305cf1325df486d6b7e/treebeard/mp_tree.py?at=default#cl-51
> >
> [3] <
> https://github.com/django/django/blob/3baebf52aa0850de3ebadcbe1eda7e6e9a2c6c44/django/db/models/deletion.py#L284
> >
>
> --
> Antoine Catton
> Software Engineer at Fusionbox, Inc.
> <https://www.fusionbox.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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/554BF717.50503%40fusionbox.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: Django banking packages

[Michael Manfre]

This group is for the discussion of developing the Django framework.
Discussions and questions related to using Django should take place on the
django-users group.

Regards,
Michael Manfre

On Mon, Jun 1, 2015, 7:11 AM Swapnil Bhadade 
wrote:

> Which are Django packages for full stack development of an e-banking web
> app  Any resources / frameworks would be of help.
> Best
>
> --
> 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/146810a4-c45c-4664-9193-15ed9961080b%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/146810a4-c45c-4664-9193-15ed9961080b%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: 1.9 release planning

[Michael Manfre]

I like Colin's proposed schedule.

Regards,
Michael Manfre

On Thu, Jun 11, 2015 at 1:12 AM, Anssi Kääriäinen 
wrote:

> +1 to Collin's release schedule.
>
> This schedule should make it extremely easy to support "develop using
> latest release, maintain using latest LTS". With the above schedule if
> you started with 1.8 you are already on LTS. If you start with 1.9,
> you should have an easy upgrade path all the way till 2.1 which is
> LTS. Also upgrading from 1.8 to 2.1 should be easy enough if you
> didn't use any deprecated features when running on 1.8.
>
>  - Anssi
>
> On Thu, Jun 11, 2015 at 12:06 AM, Tim Graham  wrote:
> > Yep, I think Collin's schedule is it. I'm happy with that option and 3rd
> > party apps shouldn't need to add any compatibility shims to support 2
> > releases -- they just need to ensure they aren't using any deprecated
> APIs.
> >
> >
> > On Wednesday, June 10, 2015 at 3:48:39 PM UTC-4, Collin Anderson wrote:
> >>
> >> Hi Tim,
> >>
> >> What I mean is we could still make it easy to support both LTS releases,
> >> even if we drop features deprecated in 1.8 before the next LTS
> according to
> >> the normal release schedule. Right? Because apps wouldn't need to use
> those
> >> deprecated features to support both 1.8 and 2.1. We could drop them in
> 2.0
> >> like normal?
> >>
> >> I'm trying to lessen the increased maintenance burden of Loic's proposal
> >> while still making it possible to easily support both LTS releases.
> >>
> >> > For "maintenance costs" I am not worried about supported deprecated
> APIs
> >> > in old releases, only how long they stay around in master as that
> could be a
> >> > barrier to innovation.
> >> Right, so the cost would be an extra 8 months before removing features
> >> deprecated in 1.9 from master.
> >>
> >> Thanks,
> >> Collin
> >>
> >> On Wednesday, June 10, 2015 at 2:09:13 PM UTC-4, Tim Graham wrote:
> >>>
> >>> Collin, I'm not following your reasoning about why dropping features
> >>> deprecated in one LTS (e.g. 1.8) in the next LTS (e.g. 2.1; I think
> you made
> >>> a typo in your timeline putting it next to 2.0?) will make it possible
> to
> >>> easily support both LTS releases? That's the purpose of Loic's
> proposal I
> >>> believe.
> >>>
> >>> For "maintenance costs" I am not worried about supported deprecated
> APIs
> >>> in old releases, only how long they stay around in master as that
> could be a
> >>> barrier to innovation.
> >>>
> >>> On Wednesday, June 10, 2015 at 1:54:53 PM UTC-4, Collin Anderson wrote:
> >>>>
> >>>> On Friday, May 8, 2015 at 12:12:37 PM UTC-4, Carl Meyer wrote:
> >>>>>
> >>>>> And there is a significant added maintenance cost to my proposal
> >>>>> compared to yours. Dropping deprecated APIs in the release after an
> LTS
> >>>>> means we still have to support those APIs for three more years
> >>>>> (possibly
> >>>>> for four or five years after they were first deprecated). Dropping
> them
> >>>>> _in_ the LTS release shortens that window drastically.
> >>>>
> >>>>
> >>>> If we release every 8 months, that means we normally support
> deprecated
> >>>> features for 2 years. If we maintained LTS compatibility, then, yes,
> that
> >>>> would mean "supporting" the APIs for more than 5 years after
> deprecation.
> >>>> But to be clear, most of that time it's only security support for
> those
> >>>> APIs, and the APIs are long gone from master. Right?
> >>>>
> >>>> Thanks,
> >>>> Collin
> >>>>
> >>>>
> >>>> On Wednesday, June 10, 2015 at 1:37:30 PM UTC-4, Collin Anderson
> wrote:
> >>>>>
> >>>>> Hi All,
> >>>>>
> >>>>> Here are some thoughts in reply to some of the comments in the
> >>>>> django-compat thread. I don't stick to the LTSs myself, but I've
> helped
> >>>>> maintain apps that have 1.4 compatibility.
> >>>>>
> >>>>> On Tuesday, June 9, 2015 at 7:05:45 PM UTC-4, Loïc Bistuer wrote:
> >>>>>>
> >>&

Re: 1.9 release planning

[Michael Manfre]

I'm +1 on the Google doc proposal and like Markus, I support relabeling 1.9
to 2.0 to line the versions up with the new paradigm without the X.1 LTS
oddball.

Regards,
Michael Manfre

On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson 
wrote:

> I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1, 3.2
> LTS, 4.0, etc.) LTS is the final of a major version number, and we
> sacrifice a little bit of strict semver, but it give some nice meaning to
> the version numbers.
>
>
> On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote:
>>
>> Thanks Loïc,
>>
>> On 06/16/2015 01:15 AM, Loïc Bistuer wrote:
>> > I've attempted to summarize the history of this thread. Note that I
>> > marked as +1 any generally positive feedback towards a given
>> > proposal, please correct if you feel misrepresented.
>> >
>> [snip]
>> >
>> > # Third iteration:
>> >
>> > 5/ Switching to Semantic Versioning
>> >
>> > Donald mentioned SemVer on IRC a few days ago. Since then various
>> > proposal were made to reconcile it with our release policy. So far
>> > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to
>> > various proposals in that direction but I don't think we have yet
>> > reached consensus on a specific one. Tim updated the Google doc to
>> > reflect my latest proposal, so including me that's 2 formal +1 for
>> > it, but I'd say we should wait for at least a couple more votes
>> > before taking it to the technical board.
>> >
>> > Refs: - http://semver.org/ - Carl's analysis
>> >
>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J
>> >
>> >
>> - Ryan's proposals
>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ
>> > - Loïc's proposal
>> >
>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ
>>
>> FWIW, I am also +1 on your proposal, as currently documented in the
>> Google doc.
>>
>> I was trying to come up with a proposal where LTS == major release for
>> the sake of argument, since it seemed like that was intuitive to at
>> least some people, but it's not worth the required lengthening of
>> deprecation paths. Your proposal is much better. (And it does make some
>> intuitive sense for the _last_ minor release in a major series to be LTS
>> rather than the first).
>>
>> Carl
>>
>>  --
> 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/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: 1.9 release planning

[Michael Manfre]

+1. I really don't like the idea of 2.x being odd.

On Mon, Jun 22, 2015 at 10:33 AM, Loïc Bistuer 
wrote:

> Just when we thought we had a winner... I'd like to make a final proposal.
>
> Instead of delaying adoption of SemVer to 3.0 we could do so in 2.0 by
> introducing the 1.10 and 1.11LTS releases.
>
> The upside is that the new policy applies right away and we avoid the
> oddball 2.0 and 2.1 releases.
>
> It's much less invasive than the previous idea of renaming 1.9 to 2.0, but
> it still requires renaming PendingDeprecationWarnings in 1.8, and both
> warnings in 1.9.
>
> What do you think?
>
> --
> Loïc
>
> > On Jun 17, 2015, at 08:47, Josh Smeaton  wrote:
> >
> > I'm also +1 on the proposal as it stands, and neutral on when the semver
> versioning should begin.
> >
> > On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote:
> > I'm +1 on the Google doc proposal and like Markus, I support relabeling
> 1.9 to 2.0 to line the versions up with the new paradigm without the X.1
> LTS oddball.
> >
> > Regards,
> > Michael Manfre
> >
> > On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson 
> wrote:
> > I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1,
> 3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and we
> sacrifice a little bit of strict semver, but it give some nice meaning to
> the version numbers.
> >
> >
> > On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote:
> > Thanks Loïc,
> >
> > On 06/16/2015 01:15 AM, Loïc Bistuer wrote:
> > > I've attempted to summarize the history of this thread. Note that I
> > > marked as +1 any generally positive feedback towards a given
> > > proposal, please correct if you feel misrepresented.
> > >
> > [snip]
> > >
> > > # Third iteration:
> > >
> > > 5/ Switching to Semantic Versioning
> > >
> > > Donald mentioned SemVer on IRC a few days ago. Since then various
> > > proposal were made to reconcile it with our release policy. So far
> > > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to
> > > various proposals in that direction but I don't think we have yet
> > > reached consensus on a specific one. Tim updated the Google doc to
> > > reflect my latest proposal, so including me that's 2 formal +1 for
> > > it, but I'd say we should wait for at least a couple more votes
> > > before taking it to the technical board.
> > >
> > > Refs: - http://semver.org/ - Carl's analysis
> > >
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J
> > >
> > >
> > - Ryan's proposals
> >
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ
> > > - Loïc's proposal
> > >
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ
> >
> > FWIW, I am also +1 on your proposal, as currently documented in the
> > Google doc.
> >
> > I was trying to come up with a proposal where LTS == major release for
> > the sake of argument, since it seemed like that was intuitive to at
> > least some people, but it's not worth the required lengthening of
> > deprecation paths. Your proposal is much better. (And it does make some
> > intuitive sense for the _last_ minor release in a major series to be LTS
> > rather than the first).
> >
> > Carl
> >
> >
> > --
> > 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 http://groups.google.com/group/django-developers.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com
> .
> >
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> >
> > --
> > GPG Fingerprint: 74DE D158 BAD0 EDF8
> > keybase.io/manfre
> >
> > --
> > 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.
> > 

Re: Django 1.9 - JSONField

[Michael Manfre]

The django-contrib-postgres JSONField takes advantage of JSON being a
native type that allows it's data fields to be used by the ORM, instead of
just a text field that wraps json.dumps() and json.loads(). All of the core
supported backends seem to have some flavor of native JSON support (MS SQL
is adding native JSON in SQL Server 2016). I haven't investigated whether
or not they could be sanely implemented as a common field. That might be a
worthwhile change to target for Django 1.10, guarded by a DatabaseFeature
for all of the earlier versions of each database that don't support it.

Regards,
Michael Manfre


On Tue, Jul 7, 2015 at 9:57 AM,  wrote:

>
> Hi all,
>
> I'd like to know why this feature will be only available on postgres and
> not as a Field for any database, like this product? This Field would be
> very usefull for many users I think.
>
> https://github.com/bradjasper/django-jsonfield
>
> https://docs.djangoproject.com/en/dev/releases/1.9/#django-contrib-postgres
>
> By.
>
> Enviado via UCSMail.
>
> --
> 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/0459e983-7098-475c-9e3f-14a076513f4a%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/0459e983-7098-475c-9e3f-14a076513f4a%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: default values on database level

[Michael Manfre]

On Wed, Jul 29, 2015 at 11:42 AM, Podrigal, Aron 
wrote:

> Hi Loic,
>
> Agree with having a db_default kwarg.
>
> I am not using multiple databases so no experiance with db routers. So how
> would should we handle routing between different databases when the
> db_default value is not compatible with that backend? for example
> Model.save(using='mysql_db') should we than use the Field.default to
> generate the default value (which is not how it works today, that the
> default is computed at instance creation). I would prefer in such a case to
> rely on the database to handle the situation by omitting that field from
> the columns list, so mysql for example would set a non nullable varchar
> column to an empty string, where with other databases it would cause an
> IntegrityError exception. and that db_default and default kwargs cannot be
> used togethor.
>

If db_default is defined for a field, then it should always be used. If the
db_default is invalid for the configured backend, then it will and should
break. We shouldn't automatically change db_default to a regular default or
do any other magic.

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

Re: future of QuerySet.extra()?

[Michael Manfre]

As some one who has had to abuse .extra() at times to make mssql things
work, I support this approach.

On Fri, Jul 31, 2015 at 4:00 PM, Tim Graham  wrote:

> I had in mind a documentation note like this:
>
> Use this method as a last resort
>
>
> This is an old API that we aim to deprecate at some point in the future.
> Use it only if you cannot express your query using other queryset methods.
> If you do need to use it, please file a ticket with your use case so that
> we can enhance the QuerySet API to allow removing extra(). We are no
> longer improving or fixing bugs for this method.
>
> On Friday, July 31, 2015 at 2:07:34 PM UTC-4, Collin Anderson wrote:
>>
>> I wonder if there's a way in the docs we can deprecate it as in "we don't
>> recommend you use it", but not actually schedule it for removal.
>>
>> On Friday, July 31, 2015 at 2:01:20 PM UTC-4, Marc Tamlyn wrote:
>>>
>>> I don't know about unmaintained, but I think there's a consensus that
>>> .extra() has a horrible API and we should do away with it eventually. That
>>> said I think there are still enough things that can't be done without it at
>>> present. A lot fewer now we have expressions, but still some.
>>>
>>> I'd be happy to put a moratorium on improving it, but we can't deprecate
>>> it yet.
>>>
>>> On 31 July 2015 at 18:58, Tim Graham  wrote:
>>>
 In light of the new expressions API, the idea of deprecating
 QuerySet.extra() has been informally discussed in IRC and elsewhere. I
 wonder if there is consensus to mark extra() as "unmaintained" and to
 suggest filing feature requests for functionality that can be performed
 through extra() but not through other existing QuerySet methods? There are
 at least several tickets (examples below) of edge cases that don't work
 with extra(). It seems like a waste of time to leave these tickets as
 accepted and to triage new issues with extra() if they won't be fixed.

 https://code.djangoproject.com/ticket/24142
 https://code.djangoproject.com/ticket/19434
 https://code.djangoproject.com/ticket/12890

 --
 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 http://groups.google.com/group/django-developers.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/django-developers/6e1be326-3b17-49ca-accf-03eec5ad41ef%40googlegroups.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> --
> 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/7c1568b6-f7f1-4aab-9263-af447e45af45%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: default values on database level

[Michael Manfre]

On Mon, Aug 3, 2015 at 9:25 AM, Podrigal, Aron 
wrote:
>
> >   - Do we want to allow extending this to defaults that are applied on
> every save (automatic database backed modified timestamps for example)?
>
> +1 for this one too.
>

This behavior would be a nice step toward computed (readonly) database
fields.



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: Django ORM query syntax enhancement

[Michael Manfre]

+1 for making it doable for 3rd party apps.

Regards,
Michael Manfre

On Tue, Aug 18, 2015 at 12:49 PM, Anssi Kääriäinen 
wrote:

> I'm still thinking we shouldn't integrate any new query syntax into
> 1.9. Instead lets make it easy to create 3rd party apps that offer
> different querying syntax, and then lets see which solution (if any)
> gets popular enough to be integrated into Django.
>
>  - Anssi
>
>
>
> On Tue, Aug 18, 2015 at 5:54 PM, Collin Anderson 
> wrote:
> > Just a quick thought: I could imagine some newbies could get confused by
> the
> > python-like syntax and try to do:
> >
> > Equal(P.user.get_full_name(), 'Bob Someone')
> >
> > I don't think it's not a huge deal, but worth noting.
> >
> > On Tuesday, August 18, 2015 at 8:00:17 AM UTC-4, Alexey Zankevich wrote:
> >>
> >> Hi all,
> >>
> >> Thanks for detailed response. I thought over the described expressions/
> >> transforms patches and here are my thoughts about the best way to
> >> implement simplified lookups.
> >>
> >> Firstly, I want to describe which properties of the new syntax seem to
> be
> >> important:
> >>
> >> 1. Using Python operators to do basic lookups as it's a natural way in
> >> Python
> >> for that.
> >>
> >> 2. Syntax should be minimalistic for basic lookups, the use of that
> >> approach
> >> will be more noticeable on multiple filter conditions. In other words,
> >> next
> >> syntax is better:
> >>
> >> >>> GameSession.objects.filter(Q.user.profile.last_login.date() ==
> >> >>> datetime.now().date)
> >>
> >> than this one
> >>
> >> >>> GameSession.objects.filter(E(F.user.profile.last_login).date() ==
> >> >>> datetime.now().date)
> >>
> >> as it requires additional calls, which makes expressions less readable.
> >>
> >> 3. I definitely like the idea of having explicit classes for lookups and
> >> transforms and think it's worth to bundle dotted query syntax with the
> >> patch.
> >> Explicit classes will separate functionality and simplify functions
> >> signature
> >> checks.
> >>
> >> I suggest a mixed approach, with next properties.
> >>
> >> 1. We will have a separate class to define query paths (let's call it P,
> >> we
> >> can still use F as "field", but having F as multipurpose class may
> confuse
> >> users, as well as implementation may become more complicated). And it
> will
> >> be
> >> the only purpose of the class. Below I'll reference it as "P" no matter
> we
> >> call
> >> it in future.
> >>
> >> 2. Any transforms and lookups will take query string or P class, as well
> >> as
> >> existing methods "select_related", "prefetch_related" and "order_by".
> The
> >> simplest implementation will be overriding __str__ method of the path
> >> class
> >> to generate related strings.
> >>
> >> >>> path = P.user.last_login_date
> >> >>> GameSession.objects.all().order_by(path)[:10]
> >>
> >> >>> print(path)
> >> user__last_login_date
> >>
> >> 3. Implement transforms and lookups as classes or functions (not bound
> to
> >> P class):
> >>
> >> >>> GameSession.objects.filter(Unaccent(P.user.location.name) == "Cote
> >> >>> d'Ivoire")
> >>
> >> It will simplify cases with parametrized transforms (ex. mentioned
> >> collate('fi')).
> >> Also eliminate fields collision with util functions like "date", which
> may
> >> be a
> >> so-called field.
> >>
> >> 4. Below is a table describing accepted passed and returned parameters:
> >>
> >> +---+---+--+
> >> |  Class/Function   |Allowed Param Types| Comparison Operators |
> >> +---+---+--+
> >> | Transform | str, P, Transform, Lookup | Return lookup|
> >> | Lookup| str, P, Transform | Raise exception  |
> >> | P |   | Return lookup|
> >> | .order_by | str, P|  |

Re: revisiting the "easy pickings" flag in Trac

[Michael Manfre]

I never liked the "easy pickings" flag either. Your proposed change would
be a good way to identify the technical ability required to make the
changes to Django. Should we have a separate drop down with options to
identify the non-technical (bikeshedding) difficulty of the ticket? There
are certain tickets that are created that are not immediately closed as
won't fix that are not a technically challenging problem, but are a huge
uphill battle to get merged.



On Thu, Aug 20, 2015 at 7:35 PM, Tim Graham  wrote:

> In my experience the "easy pickings" flag is ill-defined and insufficient
> for describing the difficulty of a ticket. I don't want to get stuck in
> categorizing tickets just for the sake of it, but I think a drop down with
> options like the following could be useful in helping contributors find
> suitable tickets:
>
> Trivial - Typos, wording tweaks, etc.
> Easy - Simple features and bugs suitable for a first-time contributor.
> Moderate - Requires a basic knowledge of Django internals.
> Hard - Requires a thorough understanding of Django internals.
> Very Hard - Refactorings or features that are difficult for experienced
> core developers.
>
> Do you think this would be useful? If so, are the selections above
> suitable?
>
> --
> 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/5544efa8-75a0-40ba-9210-bea027d32a72%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: Making the test suite run faster

[Michael Manfre]

I agree with Shai. The database backend needs to be able to control this
feature.

Regards,
Michael Manfre

On Sun, Sep 6, 2015 at 12:48 PM, Shai Berger  wrote:

> Hi,
>
> On Sunday 06 September 2015 13:06:18 Aymeric Augustin wrote:
> >
> > This will require ./runtests.py --no-parallel or ./runtests.py
> > --parallel-num=1 to run tests under Oracle. I think it’s a good tradeoff
> > because the defaults should be optimized for occasional contributors.
> >
>
> Can we somehow make this default controlled by the database backend, so
> that
> it only defaults to --parallel on backends which support it?
>
> While not many, Oracle does have its own occasional contributors, and I'm
> not
> sure this kind of change would be welcomed by the 3rd-party backends.
>
> This could be done, I think, with a feature flag on the backend
> ("supports_parallel_tests"), defaulting to False, set to True on supporting
> backends.
>
> My 2 cents,
> Shai.
>
>


-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

-- 
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/CAGdCwBv%3DyraZ7hN5rCPQAV4ySrzrW%2BUJ-P96Bb8RLGbmkkQ4fA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making max_length argument optional

[Michael Manfre]

I'm -1 on having a default max_length on CharField. We should encourage
developers to be more explicit when defining their models, not less. I've
inherited way too many databases that suffered from "VARCHAR(255)" being
chosen as the arbitrary "any field storing even a few characters will be
this length".

Instead of adding a default (and encouraging bad database schemas), what
are thoughts about adding a helper function to allow people to define their
own new CharField as a one liner? E.g. ShortCharField =
make_max_length_char_field(255)

I agree that the Postgresql specific field should exist in
django.contrib.postgres.

Regards,
Michael Manfre

On Tue, Sep 22, 2015 at 8:40 AM, Collin Anderson 
wrote:

> If anyone's curious, the mysql situation is as crazy as you might expect.
> :)
>
> The max is only determined only by the total row size (65,535 bytes) and
> the index size (767 bytes default).
>
> Mysql defaults to only allowing 3-byte (no emoji) unicode characters, so
> 65,535/3=21,845 max across the entire row (the sum of all of the maxes of
> all char/varchar columns), and each indexed field only gets 767/3=255
> characters by default.
>
> If you change to 4-byte unicode characters, (which you should, but django
> doesn't really help you out #18392), your max_lengths can add up to
> 65,535/4=16,383 characters, and if you want the field to be indexed, you
> only get 191 characters (using the default index size). It's possible to
> only index the first 767/4=191 characters of the field, but django doesn't
> really support that.
>
> Basically, 255 works pretty well by default, allowing 65,535/3/255=85
> 3-byte fields per row, and indexes just work if you stick to the default
> settings.
>
> https://dev.mysql.com/doc/refman/5.0/en/char.html
> https://code.djangoproject.com/ticket/18392
>
>
> On Tue, Sep 22, 2015 at 1:56 AM, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> Hi Shai,
>>
>> On 22 sept. 2015, at 04:22, Shai Berger  wrote:
>>
>> > I'd solve the "need to specify" issue by setting a default that is
>> > intentionally smaller than the smallest (core) backend limitation, say
>> 128.
>>
>> I would pick the highest value supported by all core backends (probably
>> 255
>> for MySQL, unless there’s something about indexes and multi-byte encodings
>> that I forget) in order to minimize the need to increase it.
>>
>> If we go for a lower value, I suggest to pick something totally arbitrary
>> like
>> 100 to make it clear that it isn't a technical limitation.
>>
>> > I"d make an "unlimited length text field" a new type of field,
>> explicitly not
>> > supported on MySql and Oracle; and I'd suggest that it can live outside
>> core
>> > for a while. so we may get an impression of how popular it really is.
>>
>> The main use case seems to be “VARCHAR() on PostgreSQL”. What about
>> defining a
>> slight variant of CharField in django.contrib.postgres that merely makes
>> the
>> max_length argument default to None?
>>
>> --
>> 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/17C37814-E6A8-4E27-B590-BF9FFF42CB20%40polytechnique.org
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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/CAFO84S5TUwLPf%3DRrGXL4%3Dvf3647CufOsijiznttVQF%2BxYHaBFg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAFO84S5TUwLPf%3DRrGXL4%3Dvf3647CufOsijiznttVQF%2BxYHaBFg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, 

Re: Static typing for python methods

[Michael Manfre]

Django can't include the inline type hinting syntax for many years, but we
can add stub files. Keeping the stubs in sync with the code will be more
effort and we'd want some sort of automated tooling to help with that, but
I'm not opposed to adding stub files for the public APIs. Assuming no core
devs chime in with a -1, I'd say create a ticket and you and/or others can
start working on a pull request.

Regards,
Michael Manfre

On Sun, Oct 11, 2015 at 5:00 AM, John Michael Lafayette <
johnmichaelreed...@gmail.com> wrote:

> Python now has static type checking. All you do is follow function
> parameters with ": paramType" and add "-> returnType" before the colon at
> the end of the function declaration and auto-complete will work on the
> return value in IntelliJ. Can you add the function parameter types and
> return types to all the functions in the public API?
>
> > > So like change this...
> > > def func(param):
> > >
> > > To this...
> > > def func(param: int) -> str:
>
> --
> 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/CACxkjvZUnbR1zXzAQnqdRS4vQ1Y_mJ%3DQ%3D-2Z-st5KDve48SBOA%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CACxkjvZUnbR1zXzAQnqdRS4vQ1Y_mJ%3DQ%3D-2Z-st5KDve48SBOA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: Fellow Report - October 17, 2015

[Michael Manfre]

Tim gave a good overview of the week. I'll focus my response on the MSSQL
roadmap.

On Sat, Oct 17, 2015 at 8:36 PM, Tim Graham  wrote:

> * Discussed the long-term roadmap for MSSQL support in Django. I'll let
> Michael speak to the details of this.
>

I had the opportunity to speak with several engineers that had intimate
knowledge of Microsoft's various SQL Server drivers; past, current, and
future. The ADO based drivers used by django-mssql will not receive any
future love from Microsoft. They don't have plans on removing them from
Windows, but the advice was to use either ODBC or FreeTDS. The fastest and
most feature rich drivers for connecting to SQL Server from Windows are the
ODBC drivers. Microsoft is actively working on updating the ODBC drivers
for Linux and expect them to be released this year. ODBC drivers for Mac
are planned for sometime next year. The next best way of connecting to SQL
Server is to use FreeTDS (without the ODBC interface), which has the
benefit of having drivers available for all OSes right now.

The short-term plan for django-mssql is to get it to pass the Django 1.8
test suite, without making any substantial changes. This will allow any
existing django-mssql users to upgrade to the Django 1.8 LTS. My long term
plan is to switch out ADO for replaceable ODBC and FreeTDS. This may follow
the current pattern Aymeric started when he created django-pymssql, or have
them both in django-mssql. After 1.8 is fully supported, I need to think,
discuss, and investigate more before making a decision.

ODBC seems to be the most performant and best option, but I have concerns
about the current lack of good drivers for Linux and Mac. If Microsoft
follows through with their commitment, then it should be a non-issue, but
I'd rather hedge my bets and ensure an easier time with drivers in the long
run. Supporting both also provides for a good way of comparing the
performance of the underlying drivers.

I plan on evaluating django-mssql, django-pyodbc-azure, and starting from
scratch to see which would be the best route for this new mssql database
backend. There are pros and cons to each. Django-mssql has a lot of legacy
cruft. Django-pyodbc-azure targets Azure SQL Server, which has some subtle
differences with Microsoft's non-cloud version of the database server.
Starting from scratch is potentially more work. Regardless of the decision,
the repo will be hosted on github.

Regards,
Michael Manfre

-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: Fellow Report - October 17, 2015

[Michael Manfre]

On Tue, Oct 20, 2015 at 3:02 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> 2015-10-20 5:04 GMT+02:00 Michael Manfre :
>
>> My long term plan is to switch out ADO for replaceable ODBC and FreeTDS.
>> This may follow the current pattern Aymeric started when he created
>> django-pymssql, or have them both in django-mssql.
>
>
> For the record, django-sqlserver did that as well. In django-pymssql, I
> chose to wrap django-mssql instead of forking it to avoid the having to
> maintain a fork until a better solution is available.
>

Thanks for the reminder. I forgot about django-sqlserver. I'll also
evaluate that backend.

Regards,
Michael

-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: Backwards-compatibility import shims

[Michael Manfre]

On Wed, Dec 30, 2015 at 11:52 AM, Tim Graham  wrote:

> For that reason, I think we should reconsider making Django's deprecation
> warnings loud by default (at least in LTS versions) [1]. Otherwise, users
> will pester library authors to fix those warnings and we haven't really
> made things easier.
>
> Instead, the idea would be for library authors to continue using the
> deprecated APIs while supporting the LTS in which they are deprecated and
> the previous LTS. When the version of Django following the LTS is released,
> library authors can then drop support for all Django versions before the
> LTS, check their package with the LTS using python -Wall and make the
> deprecation warning fixes, then seamlessly add support for the next version
> of Django.
>
> Does that make sense?
>

This makes sense to me. +1

Regards,
Michael Manfre

-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

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

Re: MySQL index hints

[Michael Manfre]

I don't think namespacing is a valid objection against query hints. By
design, query hints are specific to a database version and if a
generic django app were to include them, then the author is doing
something wrong or setting the expectation of only supporting a very
specific environment. Any core implementation for supporting this
should be minimalist and only provide a mechanism for passing some
kind of data from the QuerySet to the SQLCompiler that each backend
can optionally choose to do something with it.

I would be thrilled to be able to do use

with_hints('HASH GROUP', 'FAST 10')

and have it set

Query.query_hints = ['HASH GROUP', 'FAST 10']

I'm currently patching in support so I can do something like this for
django-mssql.

Regards,
Michael Manfre



On Jul 22, 12:03 am, Russell Keith-Magee 
wrote:
> On Fri, Jul 16, 2010 at 10:43 AM, Simon Litchfield  
> wrote:
> > Russ --
>
> > Firstly, re namespacing. No worries, let's just keep it RDBMS-
> > specific, ie --
>
> > MySQL - with_hints(use={}, force={}, ignore={})
> > Oracle - with_hints(index={}, ...)
>
> > That gives plenty of name space to breathe in.
>
> True, I don't think it's a really nice API. Why is "index" a command
> for Oracle? What happens if some other backend accepts something with
> a "index"? Personally, I'd rather see this be an explicit namespace:
>
> with_hints(mysql={...}, oracle={...})
>
> That guarantees that there isn't any cross-database clashes with hint
> names, only with database backend names. A backend can choose look at
> the full list of hints and determine which hint set it should use;
> potentially, it could even look at another backend's hints and act on
> them (although I don't know why this would be helpful, except perhaps
> in the case of a custom MySQL backend that extends the base
> capabilities).
>
>
>
> > Next --
>
> >> Using the filter/exclude name sounds interesting, but skips the first
> >> step of putting an index hint on the origin table. For example,
> >> Book.objects.filter(author__name='foo') -- now put an index hint on
> >> Book; now put one on Author. If Author and Book are an a m2m relation
> >> -- put a hint on the m2m table.
>
> > How about --
>
> >  {'book': 'book_idx', 'author': 'author_idx', 'author__name':
> > 'm2m_idx'}
>
> > Or, if you want to cover absolutely every possibility --
>
> >  {'book': 'book_idx', 'author__name__author': 'author_idx',
> > 'author__name': 'm2m_idx'}
>
> > That is, require indexes on the right side of joins to be named
> > explicitly, just in case Author is used in another join.
>
> > Sounds complicated, but obviously edge case. Common usage will be
> > simple, eg {'book':'book_idx'}.
>
> > Let me know what you think.
>
> What about when the query constructs multiple joins on a related
> table? How does the hint get named and applied then? Is it a
> consistent "a join between A and B will always get hint X"? Or do
> different joins need different hints?
>
> Yours,
> Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: MySQL index hints

[Michael Manfre]

On Aug 24, 9:30 pm, Russell Keith-Magee 
wrote:
> I don't follow your logic here.

I guess I'm more of the mindset of query hints having as much to do
with the stored data as the schema and most hints would probably be a
premature optimization or specific to a failing with a specific
database version. I do acknowledge that there are situations where
being able to ship hint corrections for known issues would be useful,
but I can't escape from the thought that those situations would attach
an expectation about which database backend should, or should probably
not be used with the app.

> And that's the proposal on the table, except that you would need to
> specify that this is a MSSQL hint, since the hint you're making isn't
> of any use to a user of any database other than MSSQL.

I'm assuming the current proposal will allow for arbitrary namespaces
that are defined simply by a backend willing to look for the specific
name. If not, there would need to be discussion about which namespaces
are defined by the core and how unsupported backends would register
new namespaces.

Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

#14299 Add additional cache.*_many functions

[Michael Manfre]

In an effort to clean up some of my project code and reduce latency
from extra cache calls, I uploaded a patch that allows a cache backend
to implement offset_many (multiple incr/decr) and add_many. Default
implementations are provided.

The patch is ready for review.

http://code.djangoproject.com/ticket/14299

--
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Preventing the leaking of sensitive information in error logs

[Michael Manfre]

On Jun 1, 5:53 am, Luke Plant  wrote:
> Would it possible to make the sensitive decorator add some kind of
> strategy object to the request, which itself is responsible for the
> filtering, rather than a simple boolean flag? The strategy object
> interface might be:
>
> class ExceptionReporterFilter(object):
>     def show_request(self, request):
>         # return True or False
>
>     def filter_request_POST(self, request, post_dict):
>         # if show_request is True, this is passed request.POST
>         # and returns a sanitised version
>
>     def show_traceback(self, request):
>         # True or false
>
>     def show_traceback_vars(self, request):
>         # called only if show_traceback() returns True
>
>     def filter_traceback_vars(self, request, tb_frame, vars):
>         # filters vars to be shown at each level.
>
> OK, could get carried away there - maybe we should start simple, e.g.
> just 'show_request' and 'show_traceback_vars'. But something like that
> would allow us to provide a working 'sensitive' decorator, but with a
> mechanism that allows for something more fine-grained, and allows us to
> add more features to it easily in the future. For the admin and CBVs it
> would work as well, since there are always places you can override a
> method and attach something to the request object.

Being able to filter at the scope of a view is a must and I like this
approach, but I'm not sure that I like having to control filtering of
the entire traceback at the scope of a view. That could lead to
needing to repeat parts of filtering on lots of views, if code is
reused often.

I wonder if it would make sense to handle the traceback and vars
filtering with a mechanism similar to __traceback_hide__. This would
allow controlling leakage per frame and make it less likely to be
missed on view.

Example:
def do_stuff():
  ...
do_stuff.__traceback_filter_vars__ = ['credit_card', 'password',
'launch_codes']


> If I'm thinking correctly, with an additional method like
> 'filter_settings', it might be possible to have a default
> ExceptionReporterFilter that does the filtering of settings that is
> currently hardcoded into django/views/debug.py.

You're correct. 'cleanse_settings' with the hardcoded HIDDEN_SETTINGS
re.

Regards.
Michael Manfre

-- 
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: Preventing the leaking of sensitive information in error logs

[Michael Manfre]

On Jun 2, 3:33 pm, Luke Plant  wrote:
> On 02/06/11 19:45, Michael Manfre wrote:
> > On Jun 1, 5:53 am, Luke Plant  wrote:
> >> Would it possible to make the sensitive decorator add some kind of
> >> strategy object to the request, which itself is responsible for the
> >> filtering, rather than a simple boolean flag? The strategy object
> >> interface might be:
>
> >> class ExceptionReporterFilter(object):
> >>     def show_request(self, request):
> >>         # return True or False
>
> >>     def filter_request_POST(self, request, post_dict):
> >>         # if show_request is True, this is passed request.POST
> >>         # and returns a sanitised version
>
> >>     def show_traceback(self, request):
> >>         # True or false
>
> >>     def show_traceback_vars(self, request):
> >>         # called only if show_traceback() returns True
>
> >>     def filter_traceback_vars(self, request, tb_frame, vars):
> >>         # filters vars to be shown at each level.
>
> >> OK, could get carried away there - maybe we should start simple, e.g.
> >> just 'show_request' and 'show_traceback_vars'. But something like that
> >> would allow us to provide a working 'sensitive' decorator, but with a
> >> mechanism that allows for something more fine-grained, and allows us to
> >> add more features to it easily in the future. For the admin and CBVs it
> >> would work as well, since there are always places you can override a
> >> method and attach something to the request object.
>
> > Being able to filter at the scope of a view is a must and I like this
> > approach, but I'm not sure that I like having to control filtering of
> > the entire traceback at the scope of a view. That could lead to
> > needing to repeat parts of filtering on lots of views, if code is
> > reused often.
>
> I'm not quite sure what you're saying. In my proposal above, the
> 'filter_traceback_vars' would only be used if 'show_traceback_vars'
> returned True, and by default it would return all vars. So you wouldn't
> be forced to do any filtering on that level.
>
> Since you could re-use your filtering class for multiple views, and you
> can implement it how you want, there would be no need to repeat the
> definition of the filtering.

An all or nothing filter, while helpful does reduce the usefulness of
the traceback. I'd prefer to have the option to filter out only the
offending variables in an easy to maintain way.

Lets assume that there are three functions with some vars that need to
be filtered out (func_a, func_b, func_c). These functions are used by
a dozen views across various apps in your project; some use all, most
use one or many of these functions. I'm looking to avoid needing to
maintain a hierarchy of filters (or a single filter that knows about
all sensitive functions) to handle all of the potential sensitive
frames that might be called by a given view. I also don't want to add
a generic filter to every view in the project to prevent the situation
where a new view uses a function that a few frames down uses one of
the sensitive functions without the author realizing it.

I guess what I proposed would be best applied to
django.views.debug.ExceptionReporter, so it is not necessary to apply
a view filter if you only need to filter out variables in various
frames.

On Jun 2, 3:33 pm, Luke Plant  wrote:
> > I wonder if it would make sense to handle the traceback and vars
> > filtering with a mechanism similar to __traceback_hide__. This would
> > allow controlling leakage per frame and make it less likely to be
> > missed on view.
>
> > Example:
> > def do_stuff():
> >   ...
> > do_stuff.__traceback_filter_vars__ = ['credit_card', 'password',
> > 'launch_codes']
>
> I'm not sure this even possible - can you go from a traceback frame to
> the *function* object? __traceback_hide__ is a local attribute, not a
> function attribute.

It's possible. The traceback provides the function name, locals and
globals as seen by the frame.

function_name = tb.tb_frame.f_code.co_name
func = tb.tb_frame.f_globals.get(function_name)

On Jun 2, 3:33 pm, Luke Plant  wrote:
> We could do the same with __traceback_filter_vars__ and make a local
> variable. But that could be an implementation detail of the
> ExceptionReporterFilter (just as respecting __traceback_hide__ would be).

A disadvantage of using a local variable is that the only way a
developer can flag a 3rd party function is by forking the code.
Patching an attribute on to a function is a much more flexible option.

Regards,
Michael Manfre

-- 
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: Making sitemaps more extensible (or providing for existing extensions)

[Michael Manfre]

Ticket #15829 (https://code.djangoproject.com/ticket/15829) includes a
patch that allows exposing the item object the template, which is all
that is needed to support any of the specific sitemap extensions.

Regards,
Michael Manfre

On Jun 22, 8:05 pm, Jeremy Dunck  wrote:
> Referring to Django's support for 
> sitemaps:https://code.djangoproject.com/browser/django/trunk/django/contrib/si...https://docs.djangoproject.com/en/1.3/ref/contrib/sitemaps/
>
> In addition to the standard sitemaps, Google also specifies some 
> extensions:http://www.google.com/support/webmasters/bin/topic.py?hl=en&topic=20986
> (Does anyone know of other extensions to sitemaps?)
>
> The purpose of these extensions are to give more info on
> semi-structured content and a better search result.
>
> In an internal codebase, we have video and news extensions now.  This
> involves a fair bit of code duplication -- Sitemap.items and
> Sitemap.get_urls, as well as a template that is roughly a copy of the
> stock sitemaps.xml with some additional values.
>
> I was thinking a few small changes could make this customizable with
> less code duplication --
>   1) .get_urls could call a per-item hook, .get_extra(item, url_info)
> to annotate the stock url_info.
>   2) the stock sitemap.xml could have blocks for adding namespaces as
> well as a block to dump the extra attributes into.
>   3) the Sitemap object could grow a template_name attribute so that
> where section is not None, a single urlconf declaration could be used
> with different templates.
>
> Outside core, a small project could then exist which implements all
> the existing format extensions.
>
> Thoughts?

-- 
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.

5 for 1

[Michael Manfre]

I reviewed:
#16358
#16355
#16359
#16353
#16316

Please look at #15829 (https://code.djangoproject.com/ticket/15829).

Thanks,
Michael Manfre

-- 
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: Exceptions thrown from middleware

[Michael Manfre]

I opened ticket #12250 for this exact reason a while ago. It's
currently design decision needed. I'm still in favor of giving
middleware a chance to handle errors raised by middleware.

https://code.djangoproject.com/ticket/12250

Regards,
Michael

On Sep 1, 11:48 am, Tom Evans  wrote:
> Hi all
>
> Currently, if a view throws an exception, the middleware classes that
> have a process_exception method will be called in reverse order to see
> if one of them can handle it and return a valid response before
> django's default exception handling takes over.
>
> This doesn't hold true for middleware classes themselves - any
> exception raised from a middleware's process_{request,view,response}
> is immediately handled by django's default exception handling, and
> there is no way of handling that exception more cleanly.
>
> The use case I saw for this was for a series of exceptions that
> middleware classes could raise, which would then be handled by another
> piece of middleware. As an example, my project has a bunch of
> automatic authenticators - IP based, SAML based, crufty tokens
> produced by Lotus Notes - but they failures in all of them should be
> handled the same. Raising a generic exception in the appropriate
> middleware, and then handling it in another middleware class seemed a
> nice clean way of doing this, I was disappointed when I read
> core/handlers/base.py
>
> It wouldn't be tricky to change this so that exceptions raised from
> middleware can be handled by middleware, but obviously this would be a
> not inconsequential change in behaviour..
>
> Thoughts?
>
> Cheers
>
> Tom

-- 
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: Testing generated SQL under different backends

[Michael Manfre]

On Tue, May 28, 2013 at 2:26 AM, Anssi Kääriäinen
wrote:

> On 27 touko, 20:15, Shai Berger  wrote:
> > On Monday 27 May 2013 19:37:55 Carl Meyer wrote:
> > I think a better solution for this is to keep the original method, and
> mark it
> > with skipUnless(is_core_db) -- we'd need to define is_core_db for that,
> of
> > course; this could also serve as an easy-to-grep marker for "general
> > functionality test, with backend variations" -- which I think would be
> quite
> > useful for 3rd-party backend writers.
>

Having vendor checks inside of a test case is painful for non-core
backends, but I don't like the approach of entirely skipping these cases
because one of the core backends needs to do something different. The
existing database features are a bit kludgey, largely due to poor feature
naming, inappropriate feature reuse, and sometimes a simple flag doesn't
work, but I think that it is still a decent enough solution for the problem
of multiple backends.


> Traditionally a backend features has been used for this. So, add some
>  feature like "produces_extra_sql_for_drop_table", if so we skip based
> on that. This unfortunately leads to features that make no sense
> except when combined with the test suite.


Many of the existing features are only used by the test suite, and most of
the ones changed by django-mssql only impact testing. Verifying
functionality between different databases is less forgiving than simply
using the functionality; Most users don't care whether the backend needed 2
or 3 queries to complete the task.


> One idea is to somehow include a subclass of problematic test classes
> in each backend. The backend can alter or skip those tests that are
> backend specific. There are a couple of test apps that should work in
> this way (introspection, backends, inspectdb, maybe more).
>
> I don't know how to make this actually work so that Django's test
> runner finds the correct test class from the backend's test module
> instead of the generic backends test class. Optimally a backend could
> subclass any test class to specialize or skip tests.
>

django.tests.runtests.setup already has special handling for adding gis
test apps. Something similar could be used to for database backends. Not
100% sure what would be a good way of flagging core tests as needing to be
skipped or wrapped to expect failure, but we might be able to avoid that
issue entirely with a combination of database feature flags and moving the
vendor specific problem cases to the respective backends.


> For 3rd party backend support in general: My opinion is that we should
> include them all in core. The rules would be:
>

By "them", do you mean 3rd party backend tests or the entire 3rd party
backend?

Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Testing generated SQL under different backends

[Michael Manfre]

On Fri, May 31, 2013 at 8:51 AM, Marc Tamlyn  wrote:

> In terms of non-core backends (and I include Oracle in this) - my
> preferred option would not be to include them all in core Django, but to
> collate them in and manage them under the Django project - i.e.
> github.com/django/django-mssql. These are "looked after" by the Django
> project to ensure that there is one place to find that code base, but are
> externally maintained. This is effectively similar to the way that
> localflavor is progressing, although we should wait and see how that plays
> out first - there are some teething issues there at the moment.


Django-mssql can be installed with pip and the project's pages (code, docs,
etc) are the first several hits on the popular search engines. Moving a
repo for the sake of moving it is a non starter for django-mssql. I'm
guessing that most of the other 3rd party database backends would object as
well, especially those not currently hosted on github. Relocating a repo is
disruptive to the developer(s) and also the users. I've gone through this
once when I moved the project from google code to bitbucket, which had the
huge benefit of making it easier and more enjoyable for me to work on the
project.

The disruption associated with relocating the project in to the core would
at least be balanced by many benefits. Just to name a few, easier test
integration, backend's issues in trac, no more django version/feature
checking in the backend, and more eyes watching commits (even if no one
else works on the backend). There is also the potential of easily fixing
the poorly named flags on DatabaseFeature.

Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Meta-Proposal: Write *above* quotations in mailing list replies

[Michael Manfre]

On Tue, Jun 4, 2013 at 1:14 PM, Yo-Yo Ma  wrote:

> Thoughts?
>
> I think we should all continue to write messages the way we deem best on
an email by email basis. The content of the message is more important than
whether we reply above or below and it's basically impossible for everyone
to consistently adhere to the same style without enforcement. Trying to
enforce guidelines would be more futile than trying to keep people from
posting django-users questions here.

Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: rename django-developers to django-contributors

[Michael Manfre]

Renaming a large mailing list is a non-trivial task that will result in
causing confusion for everyone subscribed to the list, instead of a the
occasional person posting to the wrong list. I cannot speak on behalf of
Django, but I think renaming the list is as likely to happen as Django 1.8
being a clean rewrite in PHP.

Regards,
Michael Manfre


On Tue, Jul 2, 2013 at 2:33 PM, Wim Feijen  wrote:

> Hi all,
>
> Many people post django-users questions to this group by accident. I find
> the name of our group to be misleading: it seems to refer to people who
> develop in django, but actually it is meant for people contributing to
> django.
>
> To limit confusion, my proposal is to rename django-developers to
> django-contributors.
>
> In addition, maybe django-users can be renamed as well, because the
> concept of a User in django is different from a django programmer.
>
> Regards,
>
> Wim
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Michael Manfre]

Has anyone thought to contact HostGator and see how they would react to
Django dropping FastCGI and/or whether they would be willing to support a
WSGI option.

Regards,
Michael Manfre


On Mon, Jul 15, 2013 at 12:44 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> On Mon, Jul 15, 2013 at 10:06 AM, Curtis Maloney <
> cur...@acommoncreative.com> wrote:
>
>> As much as I recognise FastCGI is pretty much a dead technology in the
>> Python world, for people stuck with cPanel sites like HostGator, it still
>> appears to be, pretty much, the only option.
>>
>> And installing uWSGI there is simply not an option there.
>>
>> So unless there's a pure python FastCGI -> WSGI library built that
>> supports Django, we're just closing the door on this avenue...
>>
>> [I say this despite my personal loathing of HostGator... :)]
>>
>
> This would be my concern as well.
>
> I have no love for FastCGI as a platform, but there's a wide range of
> hosting providers out there, especially at the cheap end, that don't
> provide a WSGI option.
>
> The right option here may well be to say "Tough Luck" to these people and
> and encourage them to move to different hosting providers. However, I don't
> want to rush into this decision without considering the effect on the low
> end of our user base.
>
> Yours,
> Russ Magee %-)
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Support Negative Indexing on QuerySets

[Michael Manfre]

Is that from django-pyodbc or a very old version of django-mssql?

The recent versions of django-mssql use SELECT ROW_NUMBER() OVER (...) to
avoid some of the issues with flipping the order multiple times. The
biggest issue is that order is not guaranteed without explicitly specifying
the order for all columns.

Regards,
Michael Manfre



On Wed, Jul 31, 2013 at 2:58 PM, Richard Laager  wrote:

> On Wed, 2013-07-31 at 13:01 +0100, Simon Riggs wrote:
> > 3) retrieve via DESC, apply LIMIT and then re-sort by ASC using derived
> table
> ...
> > (3) would require two sorts on the data like this
> >
> > SELECT * FROM (rest-of-query ORDER BY ... DESC LIMIT n ) ORDER BY ... ASC
>
> I haven't followed this thread closely, but in case this is relevant...
> The MSSQL plugin (at least for old versions of SQL Server) uses*
> something this already. For example, in the following scenario
> (extraneous columns omitted):
>
> In [4]: User.objects.order_by('username')[20:30]
> Out[4]: Executing SQL:
> SELECT *
> FROM (
>   SELECT TOP 10 *
>   FROM (
> SELECT TOP 30 [users].[id], [users].[username] AS OrdAlias1 FROM
> [users]
> ORDER BY OrdAlias1 ASC
>   ) AS [users]
>   ORDER BY OrdAlias1 DESC
> ) AS [users]
> ORDER BY OrdAlias1 ASC
>
> * I didn't test the latest version of it or Django.
>
> --
> Richard
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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.
For more options, visit https://groups.google.com/groups/opt_out.