Re: simplifying the default template context_processors

[Russell Keith-Magee]

On Sun, Jan 11, 2015 at 11:33 AM, Collin Anderson 
wrote:

> Hi All,
>
> Based on the early feedback, here's a scaled back proposal:
>
> 1. In the project_template settings.py for new projects:
> - Enable the request context processor
> - Keep the auth context processor
> - Remove the rest (you can always install them by hand).
>

TEMPLATE_CONTEXT_PROCESSORS isn't in the project template at present; it is
a default value inherited from global settings, whose initial value is:

TEMPLATE_CONTEXT_PROCESSORS = (
'django.contrib.auth.context_processors.auth',
'django.template.context_processors.debug',
'django.template.context_processors.i18n',
'django.template.context_processors.media',
'django.template.context_processors.static',
'django.template.context_processors.tz',
# 'django.template.context_processors.request',
'django.contrib.messages.context_processors.messages',
)

ISTM that we can't pare that down with just auth and request without having
some pretty profound consequences on existing sites.

It also points out a second use case: the messages context processor
shouldn't need to be manually installed; it should be automatically added
as part of app configuration, if and only if messages is in INSTALLED_APPS.
AppConfigs should make that sort of thing possible. If we're tinkering with
context_processors, we might as well fix *all* the problems (although this
is starting to looks like a 1.9-timeline project...)

2. Make the admin work without needing specific context_processors enabled.
>

This second point I definitely agree with. If anything, I think it's an
argument for the "hierarchical URL config" thing; there isn't an inherent
problem with context processors, it's that you need to have specific
context processors in place in order for admin to work, and you shouldn't
need to have 2+ pieces of configuration to get an app to work.

Russ %-)

-- 
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/CAJxq84--0azC5TmYWsudODfCRUZACoO8_o2H8uFjw%3D-djsgyxA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: simplifying the default template context_processors

[Josh Smeaton]

>From my experience some reusable apps require (in their documentation) that 
specific context_processors are installed. I'm also -0 unless some decent 
alternative exists and there's a convincing argument why they aren't a good 
feature to have.

Cheers

On Sunday, 11 January 2015 14:33:44 UTC+11, Collin Anderson wrote:
>
> Hi All,
>
> Based on the early feedback, here's a scaled back proposal:
>
> 1. In the project_template settings.py for new projects:
> - Enable the request context processor
> - Keep the auth context processor
> - Remove the rest (you can always install them by hand).
> 2. Make the admin work without needing specific context_processors enabled.
>
> It sounds like context_processors as a feature are here to stay, but here 
> are some alternatives anyway:
> - Request attributes added by a middleware, like request.cart for a store. 
> These can also be used in views.
> - Assignment tags, like {% get_navigation as nav %}. I agree creating 
> custom template tags is not fun.
>
> Reusable apps can't assume specific context_processors are installed and 
> may need to use alternatives anyway.
>
> Collin
>
> On Saturday, January 10, 2015 at 6:42:21 PM UTC-5, Russell Keith-Magee 
> wrote:
>>
>>
>> On Sun, Jan 11, 2015 at 6:40 AM, Collin Anderson  
>> wrote:
>>
>>> Hi All,
>>>
>>> In talking to Aymeric and other developers, we're starting to think 
>>> about the usefulness of global template context_processors. It seems to us 
>>> that ideally you should only need the "request" context processor. You 
>>> could even imagine removing context_processors all together and having 
>>> render() and class based views simply put the request in the context.
>>>
>>> Some ways to avoid context processors:
>>> {% static "my.css" %} instead of {{ STATIC_URL }} (a good idea 
>>> regardless)
>>> {{ mediafile.url }} instead of {{ MEDIA_URL }}
>>> {{ request.user }} instead of {{ user }}
>>> {% get_current_timezone as TIME_ZONE %}
>>> {% get_current_language as LANGUAGE_CODE %}
>>>
>>> I propose:
>>>
>>> - Enabling the request context processor for new projects.
>>> - Modifying the admin to work without context processors. 
>>> https://code.djangoproject.com/ticket/24117
>>> - Removing the other context processors for new projects. (Possibly 
>>> waiting for 1.9).
>>> - Possibly adding `request.messages` similar to `request.user`.
>>> - Maybe adding `user.perms` or a template tag to replace {{ perms }}
>>>
>>> This would be a somewhat controversial change. I think django originally 
>>> tried hard to keep the request as separate from the response as possible. 
>>> This would tie the two together even more. In my experience working with 
>>> django projects, it's often very helpful to have the request object 
>>> directly available in templates.
>>>
>>> What do you think?
>>>
>>>
>> I feel like I've missed part of a discussion. We're talking about the 
>> contents of TEMPLATE_CONTEXT_PROCESSORS, right? What exactly is the issue 
>> with global context processors? 
>>
>> Speaking personally - I'm definitely using global context processors at 
>> the moment, and it isn't clear to me what alternative you're proposing.
>>
>> My use case - my site is multi-tenant, and on every request, I need to 
>> exact who the tenant is, and a couple of important attributes of the user 
>> in light of that tenancy. These attributes are all used in my site base 
>> template, so it's not like they are only used on some views - they really 
>> are used globally.
>>
>> However, I think my use case ultimately isn't that much different to the 
>> messages case. contrib.messages is an optional app; if you're using it, 
>> then you're probably going to have a place in your base template where you 
>> want to display those messages. Making every view manually define that they 
>> want to have messages available sounds extremely onerous; it would be 
>> trivial to accidentally forget to add messages handling to a view, and site 
>> behavior would be dramatically impacted. 
>>
>> At a conceptual level, I have no problem with the idea that there may be 
>> a collection of context variables that need to be applied to *every* view - 
>> or, at the very least, a significant subset of pages. I can see how you 
>> might couple reworked context processors and middleware into a reworked 
>> hierarchical URL structure (so a URL subtree has a particular set of 
>> context processors and middlewares; subtrees of that subtree inherit those 
>> augmentations; by default, there's only one URL subtree, so context 
>> processors and middlewares are global). 
>>
>> So, unless there's a particularly compelling technical reason that I'm 
>> missing, or an equally "global" alternative being proposed, I'm -1 to 
>> removing TEMPLATE_CONTEXT_PROCESSORS.
>>
>> Yours,
>> Russ Magee %-)
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe 

Re: simplifying the default template context_processors

[Collin Anderson]

Hi All,

Based on the early feedback, here's a scaled back proposal:

1. In the project_template settings.py for new projects:
- Enable the request context processor
- Keep the auth context processor
- Remove the rest (you can always install them by hand).
2. Make the admin work without needing specific context_processors enabled.

It sounds like context_processors as a feature are here to stay, but here 
are some alternatives anyway:
- Request attributes added by a middleware, like request.cart for a store. 
These can also be used in views.
- Assignment tags, like {% get_navigation as nav %}. I agree creating 
custom template tags is not fun.

Reusable apps can't assume specific context_processors are installed and 
may need to use alternatives anyway.

Collin

On Saturday, January 10, 2015 at 6:42:21 PM UTC-5, Russell Keith-Magee 
wrote:
>
>
> On Sun, Jan 11, 2015 at 6:40 AM, Collin Anderson  > wrote:
>
>> Hi All,
>>
>> In talking to Aymeric and other developers, we're starting to think about 
>> the usefulness of global template context_processors. It seems to us that 
>> ideally you should only need the "request" context processor. You could 
>> even imagine removing context_processors all together and having render() 
>> and class based views simply put the request in the context.
>>
>> Some ways to avoid context processors:
>> {% static "my.css" %} instead of {{ STATIC_URL }} (a good idea regardless)
>> {{ mediafile.url }} instead of {{ MEDIA_URL }}
>> {{ request.user }} instead of {{ user }}
>> {% get_current_timezone as TIME_ZONE %}
>> {% get_current_language as LANGUAGE_CODE %}
>>
>> I propose:
>>
>> - Enabling the request context processor for new projects.
>> - Modifying the admin to work without context processors. 
>> https://code.djangoproject.com/ticket/24117
>> - Removing the other context processors for new projects. (Possibly 
>> waiting for 1.9).
>> - Possibly adding `request.messages` similar to `request.user`.
>> - Maybe adding `user.perms` or a template tag to replace {{ perms }}
>>
>> This would be a somewhat controversial change. I think django originally 
>> tried hard to keep the request as separate from the response as possible. 
>> This would tie the two together even more. In my experience working with 
>> django projects, it's often very helpful to have the request object 
>> directly available in templates.
>>
>> What do you think?
>>
>>
> I feel like I've missed part of a discussion. We're talking about the 
> contents of TEMPLATE_CONTEXT_PROCESSORS, right? What exactly is the issue 
> with global context processors? 
>
> Speaking personally - I'm definitely using global context processors at 
> the moment, and it isn't clear to me what alternative you're proposing.
>
> My use case - my site is multi-tenant, and on every request, I need to 
> exact who the tenant is, and a couple of important attributes of the user 
> in light of that tenancy. These attributes are all used in my site base 
> template, so it's not like they are only used on some views - they really 
> are used globally.
>
> However, I think my use case ultimately isn't that much different to the 
> messages case. contrib.messages is an optional app; if you're using it, 
> then you're probably going to have a place in your base template where you 
> want to display those messages. Making every view manually define that they 
> want to have messages available sounds extremely onerous; it would be 
> trivial to accidentally forget to add messages handling to a view, and site 
> behavior would be dramatically impacted. 
>
> At a conceptual level, I have no problem with the idea that there may be a 
> collection of context variables that need to be applied to *every* view - 
> or, at the very least, a significant subset of pages. I can see how you 
> might couple reworked context processors and middleware into a reworked 
> hierarchical URL structure (so a URL subtree has a particular set of 
> context processors and middlewares; subtrees of that subtree inherit those 
> augmentations; by default, there's only one URL subtree, so context 
> processors and middlewares are global). 
>
> So, unless there's a particularly compelling technical reason that I'm 
> missing, or an equally "global" alternative being proposed, I'm -1 to 
> removing TEMPLATE_CONTEXT_PROCESSORS.
>
> Yours,
> Russ Magee %-)
>
>

-- 
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/281f501a-7981-441c-8ea1-13605e075524%40googlegroups.com.
For more options, visit 

Re: simplifying the default template context_processors

[Russell Keith-Magee]

On Sun, Jan 11, 2015 at 6:40 AM, Collin Anderson 
wrote:

> Hi All,
>
> In talking to Aymeric and other developers, we're starting to think about
> the usefulness of global template context_processors. It seems to us that
> ideally you should only need the "request" context processor. You could
> even imagine removing context_processors all together and having render()
> and class based views simply put the request in the context.
>
> Some ways to avoid context processors:
> {% static "my.css" %} instead of {{ STATIC_URL }} (a good idea regardless)
> {{ mediafile.url }} instead of {{ MEDIA_URL }}
> {{ request.user }} instead of {{ user }}
> {% get_current_timezone as TIME_ZONE %}
> {% get_current_language as LANGUAGE_CODE %}
>
> I propose:
>
> - Enabling the request context processor for new projects.
> - Modifying the admin to work without context processors.
> https://code.djangoproject.com/ticket/24117
> - Removing the other context processors for new projects. (Possibly
> waiting for 1.9).
> - Possibly adding `request.messages` similar to `request.user`.
> - Maybe adding `user.perms` or a template tag to replace {{ perms }}
>
> This would be a somewhat controversial change. I think django originally
> tried hard to keep the request as separate from the response as possible.
> This would tie the two together even more. In my experience working with
> django projects, it's often very helpful to have the request object
> directly available in templates.
>
> What do you think?
>
>
I feel like I've missed part of a discussion. We're talking about the
contents of TEMPLATE_CONTEXT_PROCESSORS, right? What exactly is the issue
with global context processors?

Speaking personally - I'm definitely using global context processors at the
moment, and it isn't clear to me what alternative you're proposing.

My use case - my site is multi-tenant, and on every request, I need to
exact who the tenant is, and a couple of important attributes of the user
in light of that tenancy. These attributes are all used in my site base
template, so it's not like they are only used on some views - they really
are used globally.

However, I think my use case ultimately isn't that much different to the
messages case. contrib.messages is an optional app; if you're using it,
then you're probably going to have a place in your base template where you
want to display those messages. Making every view manually define that they
want to have messages available sounds extremely onerous; it would be
trivial to accidentally forget to add messages handling to a view, and site
behavior would be dramatically impacted.

At a conceptual level, I have no problem with the idea that there may be a
collection of context variables that need to be applied to *every* view -
or, at the very least, a significant subset of pages. I can see how you
might couple reworked context processors and middleware into a reworked
hierarchical URL structure (so a URL subtree has a particular set of
context processors and middlewares; subtrees of that subtree inherit those
augmentations; by default, there's only one URL subtree, so context
processors and middlewares are global).

So, unless there's a particularly compelling technical reason that I'm
missing, or an equally "global" alternative being proposed, I'm -1 to
removing TEMPLATE_CONTEXT_PROCESSORS.

Yours,
Russ Magee %-)

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

Re: simplifying the default template context_processors

[Marc Tamlyn]

I like it from a purity point of view, but I'm dreading updating through it
and replacing every instance of `{{ STATIC_URL }}` in my templates...

I also have a number of small projects which add a custom context processor
which add a certain queryset into the context every time because they form
a part of the page navigational architecture. I don't really want to have
to do this either 1) in every view or 2) via a custom template tag (because
I hate custom template tags). A similar example would be the
`add_page_if_missing`[1] context processor provided by feinCMS - it adds
the best matching CMS page to every view's context so your custom views
don't have to load the page themselves every time.

So I'm maybe +0 on the changes suggests, but I'm -0 on removing the whole
concept of context processors, at least without a suitable "one hit" way of
getting certain variables into the context of (nearly) every page.

Marc

[1] http://www.feinheit.ch/media/labs/feincms/api/contextprocessors.html

On 10 January 2015 at 22:40, Collin Anderson  wrote:

> Hi All,
>
> In talking to Aymeric and other developers, we're starting to think about
> the usefulness of global template context_processors. It seems to us that
> ideally you should only need the "request" context processor. You could
> even imagine removing context_processors all together and having render()
> and class based views simply put the request in the context.
>
> Some ways to avoid context processors:
> {% static "my.css" %} instead of {{ STATIC_URL }} (a good idea regardless)
> {{ mediafile.url }} instead of {{ MEDIA_URL }}
> {{ request.user }} instead of {{ user }}
> {% get_current_timezone as TIME_ZONE %}
> {% get_current_language as LANGUAGE_CODE %}
>
> I propose:
>
> - Enabling the request context processor for new projects.
> - Modifying the admin to work without context processors.
> https://code.djangoproject.com/ticket/24117
> - Removing the other context processors for new projects. (Possibly
> waiting for 1.9).
> - Possibly adding `request.messages` similar to `request.user`.
> - Maybe adding `user.perms` or a template tag to replace {{ perms }}
>
> This would be a somewhat controversial change. I think django originally
> tried hard to keep the request as separate from the response as possible.
> This would tie the two together even more. In my experience working with
> django projects, it's often very helpful to have the request object
> directly available in templates.
>
> What do you think?
>
> 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/bf74b593-3fbb-46fe-89f6-ce280124d707%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/CAMwjO1Gx29ztS9xA-cA3Pn2H9U4P6JjwPxo7fx1qqY8EBkd_Jw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multiple template engines for Django - week 13

[Aymeric Augustin]

Hello,

Here’s episode 14:
https://myks.org/en/multiple-template-engines-for-django/#2015-01-11

Hopefully I’ll reach the point where I don’t have enough material to write
a weekly update by the end of February :-)

-- 
Aymeric.



> On 4 janv. 2015, at 00:23, Aymeric Augustin 
>  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 
>>  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 
>>>  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 
  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 
>  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 
>>  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’ll merge changes that make sense regardless of the 
>> Multiple Template Engines Project in small batches, in order to minimize 
>> the size of the final pull request.
>> 
>> -- 
>> Aymeric.
>> 
>> 
>> 
>>> On 9 nov. 2014, at 22:05, Aymeric Augustin 
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> Here’s my fifth update:
>>> https://myks.org/en/multiple-template-engines-for-django/#2014-11-09
>>> 
>>> The first step of my project, as outlined in my original proposal, is 
>>> complete.
>>> 
>>> -- 
>>> Aymeric.
>>> 
>>> 
>>> 
 On 1 nov. 2014, at 23:30, Aymeric Augustin 
  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 
> 

simplifying the default template context_processors

[Collin Anderson]

Hi All,

In talking to Aymeric and other developers, we're starting to think about 
the usefulness of global template context_processors. It seems to us that 
ideally you should only need the "request" context processor. You could 
even imagine removing context_processors all together and having render() 
and class based views simply put the request in the context.

Some ways to avoid context processors:
{% static "my.css" %} instead of {{ STATIC_URL }} (a good idea regardless)
{{ mediafile.url }} instead of {{ MEDIA_URL }}
{{ request.user }} instead of {{ user }}
{% get_current_timezone as TIME_ZONE %}
{% get_current_language as LANGUAGE_CODE %}

I propose:

- Enabling the request context processor for new projects.
- Modifying the admin to work without context 
processors. https://code.djangoproject.com/ticket/24117
- Removing the other context processors for new projects. (Possibly waiting 
for 1.9).
- Possibly adding `request.messages` similar to `request.user`.
- Maybe adding `user.perms` or a template tag to replace {{ perms }}

This would be a somewhat controversial change. I think django originally 
tried hard to keep the request as separate from the response as possible. 
This would tie the two together even more. In my experience working with 
django projects, it's often very helpful to have the request object 
directly available in templates.

What do you think?

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/bf74b593-3fbb-46fe-89f6-ce280124d707%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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
> 
> .
> 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: documenting changes to the database backend API

[Ola Sitarska]

Hi Tim!

At Potato we're developing Djangae: https://github.com/potatolondon/djangae,
which is a database backend for supporting Google App Engine datastore.
We're currently only supporting 1.6, but we're about to start development
of 1.7 support.

Thanks!
Ola

On Fri, Jan 9, 2015 at 5: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
> 
> .
> 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/CAFpnBuuVQ8LyX51QA-nUbbUmK6yxMfkjieoTXZNDep6qtR%2Buww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.