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.

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

[Aymeric Augustin]

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

Re: Setting database default values in migrations (postgres)

[Shai Berger]

On Friday 31 October 2014 19:16:15 Jon Dufresne wrote:
> On Fri, Oct 31, 2014 at 9:46 AM, Andrew Godwin  wrote:
> > So, bear in mind that you can easily set these defaults yourself in a
> > migration with RunSQL if you need them for legacy purposes; that way
> > they'll get applied
> 
> Absolutely. I effectively have such a system in place at the moment.
> 
> But, my point is I am also making an effort to match Django's expected
> schema while moving away from the legacy schema. I would prefer not to
> drift too far from Django's expectations as the goal is move entirely
> to Django. This is just one more thing to keep track of and handle
> semi-manually.
> 
> All I'm saying is that if the described feature existed, it would
> benefit me and others that share my use case.

So, we should be weighing the support-transition-from-legacy use-case against 
creating a situation where field defaults get a special treatment if they are 
primitive enough (callables are out, but I am really not sure about other 
complex objects -- GIS would probably gain a new dimension of fun if it were 
to deal  with defaults, even when not callable).

I think the correct way forward for migrations is to keep as it does today -- 
requiring users to explicitly ask for db defaults (we could, as I said 
earlier, give it a nicer API than RunSQL).

As for "Django's expectations" -- while I don't think we should generate db 
defaults unless specifically asked to, I don't see where such defaults could 
get in our way. If you ever run into a situation where Django mishandles some 
table because it has defaults, that is almost for sure a bug.

My 2 cents,
Shai.

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

Re: Django's problem with db-level defaults on Oracle

[Shai Berger]

On Saturday 01 November 2014 11:55:26 Kääriäinen Anssi wrote:
> Quick question: could django set the default to to_date('2014-31-01',
> '-mm-dd')?

Yes, apparently we could, and it would solve the problem I described earlier, 
thanks. If we decide to start using defaults in the database (which I still 
think we shouldn't, because of other issues), something along these lines will 
be required.

Thanks,
Shai.

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

Fellow Report: Oct 27-31, 2014

[Berker Peksağ]

Hi all,

Here is a list of what I've worked on in the last week. You can see
more detailed version of this report (including my rough TODO list) at
https://code.djangoproject.com/wiki/DjangoFellows/BerkerPeksag.

Authored

* https://github.com/django/django/pull/3432 -- Used more specific
asserts in the Django test suite.
* https://github.com/django/django/pull/3421 -- Limited lines to 119
characters in django/{contrib,db}.
* https://github.com/django/django/pull/3439 -- Fixed #18731 -- Added
an example about customizing "makemessages" command.
* https://github.com/django/django/pull/3442 -- Converted seealso
directives to use 4 space indendation.
* https://github.com/django/django/pull/3444 -- Fixed #23575 -- Added
a code example for custom AdminSite.


Revised pull requests (fixing merge conflicts, addressing remaining
issues, adding more tests etc.)

* https://github.com/django/django/pull/3433 -- Fixed #20495 -- Added
login failure events to security logger.
* https://github.com/django/django/pull/3454 -- Escape path returned
by `HttpRequest.get_full_path()`.


Code reviews

  Django

  * https://github.com/django/django/pull/3369/ -- Fixed #9893 --
Filename could exceed max_length on a collision
  * https://github.com/django/django/pull/3447/ -- Fixed #23468 --
settings.FIXTURE_DIRS checks in loaddata command
  * https://github.com/django/django/pull/3455/ -- Fixed #23730 --
Moved support for SimpleCookie HIGHEST_PROTOCOL pickling to
http.cookie

  Python

  * http://bugs.python.org/review/22775/ -- SimpleCookie not picklable
with HIGHEST_PROTOCOL


Triaged tickets

* http://bugs.python.org/issue22758 -- Regression in Python 3.2 cookie parsing
* http://bugs.python.org/issue22775 -- SimpleCookie not picklable with
HIGHEST_PROTOCOL

--Berker

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

RE: Django's problem with db-level defaults on Oracle

[Kääriäinen Anssi]

Quick question: could django set the default to to_date('2014-31-01', 
'-mm-dd')?

From: django-developers@googlegroups.com [django-developers@googlegroups.com] 
on behalf of Shai Berger [s...@platonix.com]
Sent: Friday, October 31, 2014 17:34
To: django-developers@googlegroups.com
Subject: Django's problem with db-level defaults on Oracle

Hi Everyone,

I just mentioned in another thread that db-level defaults are particularly
troublesome on Oracle. I didn't want to burden that discussion with the
detais, but having been asked about it on IRC (thanks Josh), here they are.

The problem is caused by a combination of factors:

1) Oracle stores database-level defaults as strings, evaluated when needed.

This is not, in itself, completely insensible -- the processing and space
overheads (compared to some more "binary" representation) are negligible, and
it means defaults "4" and "sysdate()" are treated by the system uniformly.

2) Django's Oracle backend sets the date-time format to a constant (close to
ISO format), which is usually not the default.

This has been used to perform some database date-time operations by
manipulating strings -- because that way was easier to the developer
implementing them, or there wasn't proper support for the feature otherwise;
as a classic example, before 1.7, date-times used to be inserted into the
database as strings, because some special manipulation was required to make
cx_Oracle (the database driver library) support sub-second precision (thanks
jtiai). I'm not completely sure how much date-string-manipulation remains in
the Oracle backend today, but it is certainly still used for database
defaults: Oracle doesn't take parameters in DDL statements.

As a result of these two factors, when datetimes were set as default column
values (which happened a lot with South<0.7.3), the value actually stored in
the schema was a string specifying the date-time in a non-default format.
Whenever Django connected to the DB, it set the session's date-time format to
the "right" one, and so no problems were seen.

But when backing up using the oracle "exp" utility -- which, as far as I'm
aware, is pretty standard, at least as a developer backing up schemas on their
own instance -- it was still these strings that were saved; and when trying to
restore with the converse "imp", whose connection is (of course) not
controlled by Django, the utility tried to set the date-time defaults by a
format that was inappropriate for the values. This usually failed, resulting
in partial restores, which lead to a lot of pain.

If you're still here, you probably want to know how we solved the problem: Our
DBA showed us how to install a database-level trigger to change the format
whenever the relevant users logged on. This allowed us to get Oracle's "imp"
to use the right date-time formats. However, this is highly non-obvious: I,
for one, didn't even know such triggers existed.

Thanks for your attention,

Shai.

--
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/201410311734.08971.shai%40platonix.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/7CDBD1EFB267CD41949C704C14E92DBF1A714566%40HELW040.stakes.fi.
For more options, visit https://groups.google.com/d/optout.