Re: Removing Oracle from Django core in 3.0

[Mariusz Felisiak]

Hi

 I don't agree that the Oracle back-end is poor implemented (I probably 
should not treat this personally ). It is as well maintained as any other 
back-end that is in the core. We don't have much more open tickets in the 
Oracle back-end then in others and IMO it is easier to maintain it in the 
core.

>
>- *Technical:*
>   - *Oracle does not support may features*
>   - *due to its lack of features, a lot of edge case handling to the 
>   base database backend which drives overall complexity*
>
> Just like SQLite or MySQL I don't think that we should leave only 
PostgreSQL in the core . 

>
>- Development:
>   - Oracle does not run in the regular CI suite, in fact master is 
>   broken right now
>
> I don't see any failures in djangoci.com. Maybe you use an unsupported 
version of Oracle?

Best
Mariusz


W dniu niedziela, 25 listopada 2018 11:21:02 UTC+1 użytkownik Johannes 
Hoppe napisał:

> Hi there,
>
> I have recently refactored some bits in the database backend and came to 
> realize that a lot of the complexity in there comes from the poor 
> implementation of the Oracle backend.
> Fun fact, did you know that Oracle tests don't run by default and that the 
> current master, fails on oracle ;)
>
> Anyhow, I want to come to a conclusion about the following matter:
>
> Should we remove the Oracle database backend from Django core in the 3.0 
> release?
>
> Here are a couple of reasons, why I believe this to be a good idea:
>
>- License
>- Oracle is  Proprietary software
>- Money
>   - Oracle is not a sponsor of the Django Foundation, but makes 40bn 
>   in revenue
>- Technical:
>   - Oracle does not support may features
>   - due to its lack of features, a lot of edge case handling to the 
>   base database backend which drives overall complexity
>- Development:
>   - Oracle does not run in the regular CI suite, in fact master is 
>   broken right now
>   - entrance barrier for first time contributors is high
>  - one needs to accept a non open source license
>  - register with oracle
>  - go through a very complex setup process
>   
> Of course there are some users who use Oracle and I don't want to keep 
> them hanging. I simply believe the database backend should be developed 
> separately from Django.
> This could even be helpful for the Oracle community. Since oracle is 
> enterprise only, they usually looks for longer support cycles than what 
> Django want's to offer.
>
> Ok, I made my case, I am curious, what do you guys think?
>
> Best
> -Joe
>

-- 
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/b5260d36-c698-4e3f-bf28-4d7c425d691e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing Oracle from Django core in 3.0

[Dan Davis]

My employer is an Oracle shop.  I would dedicate myself to Oracle specific
bugs to prevent removing Oracle from core.   That said, we'll probably be
off Oracle and onto the cloud and Postgresql by 3.0.

On Sun, Nov 25, 2018 at 1:36 PM Adam Johnson  wrote:

> Interestingly, I didn't receive your first email Johannes, only Tim's
> reply. I can't even find it in spam. Maybe Gmail's filters highly associate
> mentions of "Oracle" with spam? :/
>
> I agree that with Tim that it's going to be easier to keep it in core if
> development is going to continue. Any suggestion that unbundling it would
> improve its support lifecycle should be well backend by Django+Oracle users
> themselves, which I take it you aren't Johannes.
>
> On Sun, 25 Nov 2018 at 17:54, Tim Graham  wrote:
>
>> I can't find a past discussion specific to Oracle, but it's not a new
>> proposal. See
>> https://groups.google.com/d/topic/django-developers/O-g06EM6XMM/discussion
>> for "Moving database backends out of the core."
>>
>> I think removing Oracle from core would only increase the maintenance
>> burden. Since Oracle has edge cases, it's useful to test those along with
>> new Django features. If the Oracle backend is in a separate repo, then
>> adding new features will often require commits to two repositories and I
>> don't know how we would run the tests with pull request X for Django and
>> pull request Y for the Oracle backend. Then we also have to release the
>> Oracle backend separately.
>>
>> djangoci.com isn't reporting any Oracle failures on master. If you've
>> found an issue, please open a ticket with details.
>>
>> We don't run the Oracle tests with pull requests because they take about
>> an hour, while other databases take about 10 minutes. It hasn't been
>> difficult to identify which pull requests require running the tests on
>> Oracle and to trigger that build with the trigger phrase.
>>
>> On Sunday, November 25, 2018 at 5:21:02 AM UTC-5, Johannes Hoppe wrote:
>>>
>>> Hi there,
>>>
>>> I have recently refactored some bits in the database backend and came to
>>> realize that a lot of the complexity in there comes from the poor
>>> implementation of the Oracle backend.
>>> Fun fact, did you know that Oracle tests don't run by default and that
>>> the current master, fails on oracle ;)
>>>
>>> Anyhow, I want to come to a conclusion about the following matter:
>>>
>>> Should we remove the Oracle database backend from Django core in the 3.0
>>> release?
>>>
>>> Here are a couple of reasons, why I believe this to be a good idea:
>>>
>>>- License
>>>- Oracle is  Proprietary software
>>>- Money
>>>   - Oracle is not a sponsor of the Django Foundation, but makes
>>>   40bn in revenue
>>>- Technical:
>>>   - Oracle does not support may features
>>>   - due to its lack of features, a lot of edge case handling to the
>>>   base database backend which drives overall complexity
>>>- Development:
>>>   - Oracle does not run in the regular CI suite, in fact master is
>>>   broken right now
>>>   - entrance barrier for first time contributors is high
>>>  - one needs to accept a non open source license
>>>  - register with oracle
>>>  - go through a very complex setup process
>>>
>>> Of course there are some users who use Oracle and I don't want to keep
>>> them hanging. I simply believe the database backend should be developed
>>> separately from Django.
>>> This could even be helpful for the Oracle community. Since oracle is
>>> enterprise only, they usually looks for longer support cycles than what
>>> Django want's to offer.
>>>
>>> Ok, I made my case, I am curious, what do you guys think?
>>>
>>> Best
>>> -Joe
>>>
>> --
>> 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/d354b7a9-d116-41e9-9b4c-f8335931957f%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Adam
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this 

Re: Password reset emails in combination with click tracking do not work with Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave

[Florian Apolloner]

I guess it would help to know how Safari's tracking protection does work (I 
do not own a Mac) -- it seems hard to imagine that an internal redirect on 
a page triggers the protection. In that sense it seems more like a 
ISP-problem like Adam pointed out.

On Sunday, November 25, 2018 at 9:39:28 AM UTC+1, Adam Johnson wrote:
>
> It sounds to me that this your email provider rewriting the link to go 
> through their tracking site, and Safari now blocks the tracking site. I 
> don't see how Django can do anything around this - the "internal token 
> redirect" (which I guess means a Django generated redirect from one page to 
> another on your site) is going to be after going through the tracking site, 
> no?
>
> On Thu, 22 Nov 2018 at 09:51, Mat Gadd > 
> wrote:
>
>> Hi all,
>>
>> I raised a ticket  
>> regarding this and was directed here to discuss the topic. The summary is 
>> that the combination of using click-tracking redirects (which are popular 
>> with a variety of email providers) with the Django contrib.auth password 
>> reset views does not work in Safari on macOS and iOS as of the latest major 
>> versions.
>>
>> It took me quite a long time to work out what was happening, so I wanted 
>> to at least raise a ticket where other people might find it, but was also 
>> hoping to start a discussion around how else the problem could be 
>> mitigated. An option to disable the internal token redirect might be 
>> useful, but that then re-opens the token up to being leaked via the 
>> HTTP_REFERER header.
>>
>> Regards,
>>  - Mat
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/20d7a1d1-9c37-44df-8d6f-577f55727efc%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> Adam
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/091e0d61-ed46-4619-9a59-1a5d078e86e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing Oracle from Django core in 3.0

[Adam Johnson]

Interestingly, I didn't receive your first email Johannes, only Tim's
reply. I can't even find it in spam. Maybe Gmail's filters highly associate
mentions of "Oracle" with spam? :/

I agree that with Tim that it's going to be easier to keep it in core if
development is going to continue. Any suggestion that unbundling it would
improve its support lifecycle should be well backend by Django+Oracle users
themselves, which I take it you aren't Johannes.

On Sun, 25 Nov 2018 at 17:54, Tim Graham  wrote:

> I can't find a past discussion specific to Oracle, but it's not a new
> proposal. See
> https://groups.google.com/d/topic/django-developers/O-g06EM6XMM/discussion
> for "Moving database backends out of the core."
>
> I think removing Oracle from core would only increase the maintenance
> burden. Since Oracle has edge cases, it's useful to test those along with
> new Django features. If the Oracle backend is in a separate repo, then
> adding new features will often require commits to two repositories and I
> don't know how we would run the tests with pull request X for Django and
> pull request Y for the Oracle backend. Then we also have to release the
> Oracle backend separately.
>
> djangoci.com isn't reporting any Oracle failures on master. If you've
> found an issue, please open a ticket with details.
>
> We don't run the Oracle tests with pull requests because they take about
> an hour, while other databases take about 10 minutes. It hasn't been
> difficult to identify which pull requests require running the tests on
> Oracle and to trigger that build with the trigger phrase.
>
> On Sunday, November 25, 2018 at 5:21:02 AM UTC-5, Johannes Hoppe wrote:
>>
>> Hi there,
>>
>> I have recently refactored some bits in the database backend and came to
>> realize that a lot of the complexity in there comes from the poor
>> implementation of the Oracle backend.
>> Fun fact, did you know that Oracle tests don't run by default and that
>> the current master, fails on oracle ;)
>>
>> Anyhow, I want to come to a conclusion about the following matter:
>>
>> Should we remove the Oracle database backend from Django core in the 3.0
>> release?
>>
>> Here are a couple of reasons, why I believe this to be a good idea:
>>
>>- License
>>- Oracle is  Proprietary software
>>- Money
>>   - Oracle is not a sponsor of the Django Foundation, but makes 40bn
>>   in revenue
>>- Technical:
>>   - Oracle does not support may features
>>   - due to its lack of features, a lot of edge case handling to the
>>   base database backend which drives overall complexity
>>- Development:
>>   - Oracle does not run in the regular CI suite, in fact master is
>>   broken right now
>>   - entrance barrier for first time contributors is high
>>  - one needs to accept a non open source license
>>  - register with oracle
>>  - go through a very complex setup process
>>
>> Of course there are some users who use Oracle and I don't want to keep
>> them hanging. I simply believe the database backend should be developed
>> separately from Django.
>> This could even be helpful for the Oracle community. Since oracle is
>> enterprise only, they usually looks for longer support cycles than what
>> Django want's to offer.
>>
>> Ok, I made my case, I am curious, what do you guys think?
>>
>> Best
>> -Joe
>>
> --
> 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/d354b7a9-d116-41e9-9b4c-f8335931957f%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1LxFXXusWe-mJA55%2BqoK-9pr3-ZAK%2BV6Kw-igqNkaggg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing Oracle from Django core in 3.0

[André Luis Pereira dos Santos]

Move database backends out of the Django's core sounds great.
 

Em domingo, 25 de novembro de 2018 15:54:21 UTC-2, Tim Graham escreveu:
>
> I can't find a past discussion specific to Oracle, but it's not a new 
> proposal. See 
> https://groups.google.com/d/topic/django-developers/O-g06EM6XMM/discussion 
> for "Moving database backends out of the core."
>
> I think removing Oracle from core would only increase the maintenance 
> burden. Since Oracle has edge cases, it's useful to test those along with 
> new Django features. If the Oracle backend is in a separate repo, then 
> adding new features will often require commits to two repositories and I 
> don't know how we would run the tests with pull request X for Django and 
> pull request Y for the Oracle backend. Then we also have to release the 
> Oracle backend separately.
>
> djangoci.com isn't reporting any Oracle failures on master. If you've 
> found an issue, please open a ticket with details.
>
> We don't run the Oracle tests with pull requests because they take about 
> an hour, while other databases take about 10 minutes. It hasn't been 
> difficult to identify which pull requests require running the tests on 
> Oracle and to trigger that build with the trigger phrase.
>
> On Sunday, November 25, 2018 at 5:21:02 AM UTC-5, Johannes Hoppe wrote:
>>
>> Hi there,
>>
>> I have recently refactored some bits in the database backend and came to 
>> realize that a lot of the complexity in there comes from the poor 
>> implementation of the Oracle backend.
>> Fun fact, did you know that Oracle tests don't run by default and that 
>> the current master, fails on oracle ;)
>>
>> Anyhow, I want to come to a conclusion about the following matter:
>>
>> Should we remove the Oracle database backend from Django core in the 3.0 
>> release?
>>
>> Here are a couple of reasons, why I believe this to be a good idea:
>>
>>- License
>>- Oracle is  Proprietary software
>>- Money
>>   - Oracle is not a sponsor of the Django Foundation, but makes 40bn 
>>   in revenue
>>- Technical:
>>   - Oracle does not support may features
>>   - due to its lack of features, a lot of edge case handling to the 
>>   base database backend which drives overall complexity
>>- Development:
>>   - Oracle does not run in the regular CI suite, in fact master is 
>>   broken right now
>>   - entrance barrier for first time contributors is high
>>  - one needs to accept a non open source license
>>  - register with oracle
>>  - go through a very complex setup process
>>   
>> Of course there are some users who use Oracle and I don't want to keep 
>> them hanging. I simply believe the database backend should be developed 
>> separately from Django.
>> This could even be helpful for the Oracle community. Since oracle is 
>> enterprise only, they usually looks for longer support cycles than what 
>> Django want's to offer.
>>
>> Ok, I made my case, I am curious, what do you guys think?
>>
>> Best
>> -Joe
>>
>

-- 
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/1606db6d-af8b-4c74-866f-bc20b195b49c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reactive frontend using Django templates?

[Christian González]

Vue.JS could be a candidate to create that. I am currently experimenting
in adding a plugin system to Django in form of an app "GDAPS" - Generic
Django App Plugin System, find it on PyPi/Gitlab. It's in a very, very
rude state at the beginning, and I am not an experienced developer.

But I'd like to try having Vue.js snippets distributed via Django
templates, and maybe variables connected automatically using a simple
REST or GraphQL interface.
I think using something "integrated" like Meteor is not the way Django
should go, as it is too "narrow" and does not allow separating the
server and client API - It's good to have an interface like REST or at
least channels which clients can consume.

But ATM it's very hard to do that without much boilerplate-coding. I
always wonder why anyone hasn't already done this.

GDAPS should be a plugin system in the first case, but I think that
having a (maybe also pluggable) frontend (like Vue, React, Angular,
Polymer etc.) there would be a good idea.

Maybe this is something completely different, but maybe you'll find some
common parts with your intentions - feel free to share ideas.

Christian


Am 21. November 2018 21:00:23 MEZ schrieb Andrew Godwin
:

Hi Brylie,

There are no such efforts at the moment - Django is still focused on
being a backend language for the most part, and we don't really have
any of the pieces in place to do dynamic template rendering. We're
more focused on providing the fundamental components to let other
people build that sort of stuff.

Andrew

On Wed, Nov 21, 2018 at 11:48 AM Brylie Christopher Oxley
mailto:bry...@amble.fi>> wrote:

Hello,
I have been developing with Meteor.js for about four years now.
One really nice aspect of Meteor is that it streams data to the
client, which in turn updates the templates (e.g. adding chat
messages to a list).

When I look for such a solution with Django, it seems that
Channels is a solution for the streaming data, but there doesn't
seem to be a way to reactively update client code generated by
Django templates without making another server request to render
the HTML.

I really like the Django template language, and don't want to
switch away to a frontend framework, for several reasons. Are
there any efforts to which I can contribute, with the goal of
adding reactivity to client-side templates generated with the
Django template language?

Best regards,
Brylie Christopher Oxley
-- 
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/82f35996-0663-43dc-951f-f2936670a37c%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4ee35cc8-2937-007d-d33c-37baa197ba23%40nerdocs.at.
For more options, visit https://groups.google.com/d/optout.

Re: Removing Oracle from Django core in 3.0

[Tim Graham]

I can't find a past discussion specific to Oracle, but it's not a new 
proposal. See 
https://groups.google.com/d/topic/django-developers/O-g06EM6XMM/discussion 
for "Moving database backends out of the core."

I think removing Oracle from core would only increase the maintenance 
burden. Since Oracle has edge cases, it's useful to test those along with 
new Django features. If the Oracle backend is in a separate repo, then 
adding new features will often require commits to two repositories and I 
don't know how we would run the tests with pull request X for Django and 
pull request Y for the Oracle backend. Then we also have to release the 
Oracle backend separately.

djangoci.com isn't reporting any Oracle failures on master. If you've found 
an issue, please open a ticket with details.

We don't run the Oracle tests with pull requests because they take about an 
hour, while other databases take about 10 minutes. It hasn't been difficult 
to identify which pull requests require running the tests on Oracle and to 
trigger that build with the trigger phrase.

On Sunday, November 25, 2018 at 5:21:02 AM UTC-5, Johannes Hoppe wrote:
>
> Hi there,
>
> I have recently refactored some bits in the database backend and came to 
> realize that a lot of the complexity in there comes from the poor 
> implementation of the Oracle backend.
> Fun fact, did you know that Oracle tests don't run by default and that the 
> current master, fails on oracle ;)
>
> Anyhow, I want to come to a conclusion about the following matter:
>
> Should we remove the Oracle database backend from Django core in the 3.0 
> release?
>
> Here are a couple of reasons, why I believe this to be a good idea:
>
>- License
>- Oracle is  Proprietary software
>- Money
>   - Oracle is not a sponsor of the Django Foundation, but makes 40bn 
>   in revenue
>- Technical:
>   - Oracle does not support may features
>   - due to its lack of features, a lot of edge case handling to the 
>   base database backend which drives overall complexity
>- Development:
>   - Oracle does not run in the regular CI suite, in fact master is 
>   broken right now
>   - entrance barrier for first time contributors is high
>  - one needs to accept a non open source license
>  - register with oracle
>  - go through a very complex setup process
>   
> Of course there are some users who use Oracle and I don't want to keep 
> them hanging. I simply believe the database backend should be developed 
> separately from Django.
> This could even be helpful for the Oracle community. Since oracle is 
> enterprise only, they usually looks for longer support cycles than what 
> Django want's to offer.
>
> Ok, I made my case, I am curious, what do you guys think?
>
> Best
> -Joe
>

-- 
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/d354b7a9-d116-41e9-9b4c-f8335931957f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: TestCase.setUpTestData in-memory data isolation.

[Adam Johnson]

I have run into this problem myself in the past. On a previous project we
added a helper function to make deepcopy's of named attributes during
setUp().

>From a check against a few projects and Django's test suite[2] I have only
> identified a single issue which is that attributes assigned during
> `setUpTestData` would now have to be `deepcopy()`able but it shouldn't be
> a blocker given `Model` instance are.


I think this is too much of an ask for backwards compatibility. Lots of
things aren't deepcopy-able, as per its docs:

This module does not copy types like module, method, stack trace, stack
> frame, file, socket, window, array, or any similar types. It does “copy”
> functions and classes (shallow and deeply), by returning the original
> object unchanged; this is compatible with the way these are treated by the
> pickle module.


How about adding a container object to TestCase, which deepcopy()'s its
attributes on setUp. It could be called something short like "data', which
would make your example:

class BookTests(TestCase):
@classmethod
def setUpTestData(cls):
cls.data.author = Author.objects.create()
cls.data.book = cls.author.books.create()

def test_relationship_preserved(self):
self.assertIs(self.data.book.author, self.data.author)

On Sat, 24 Nov 2018 at 03:29, charettes  wrote:

> Dear developers,
>
> Django 1.8 introduced the `TestCase.setUpTestData()` class method as a
> mean to
> speed up test fixtures initialization as compared to using `setUp()`[0].
>
> As I've come to use this feature and review changes from peers using it in
> different projects the fact that test data assigned during its execution
> couldn't be safely altered by test methods without compromising test
> isolation
> has often be the source of confusion and frustration.
>
> While the `setUpTestData` documentation mentions this limitation[1] and
> ways to
> work around it by using `refresh_from_db()` in `setUp()` I believe it
> defeats
> the whole purpose of the feature; avoiding unnecessary roundtrips to the
> database to speed up execution. Given `TestCase` goes through great
> lengths to
> ensure database level data isolation I believe it should do the same with
> class
> level in-memory data assigned during `setUpTestData`.
>
> In order to get rid of this caveat of the feature I'd like to propose an
> adjustment to ensure such in-memory test data isolation.
>
> What I suggest doing is wrapping all attributes assigned during
> `setUpTestData`
> in descriptors that lazily return `copy.deepcopy()`ed values on instance
> attribute accesses. By attaching the `deepcopy()`'s memo on test instances
> we
> can ensure that the reference graph between objects is preserved and thus
> backward compatible.
>
> In other words, the following test would pass even if `self.book` is a deep
> copy of `cls.book`.
>
> class BookTests(TestCase):
> @classmethod
> def setUpTestData(cls):
> cls.author = Author.objects.create()
> cls.book = cls.author.books.create()
>
> def test_relationship_preserved(self):
> self.assertIs(self.book.author, self.author)
>
> Lazily returning `deepcopy'ies and caching returned values in `__dict__` à
> la
> `cached_property` should also make sure the slight performance overhead
> this
> incurs is minimized.
>
> From a check against a few projects and Django's test suite[2] I have only
> identified a single issue which is that attributes assigned during
> `setUpTestData` would now have to be `deepcopy()`able but it shouldn't be
> a blocker given `Model` instance are.
>
> In order to allow other possible issues from being identified against
> existing
> projects I packaged the proposed feature[3] and made it available on
> pypi[4]. It
> requires decorating `setUpTestData` methods but it shouldn't be too hard to
> apply to your projects if you want to give it a try.
>
> Given this reaches consensus that this could be a great addition I'd file
> a ticket and finalize what I have so far[2].
>
> Thank your for your time,
> Simon
>
> [0]
> https://docs.djangoproject.com/en/1.8/releases/1.8/#testcase-data-setup
> [1]
> https://docs.djangoproject.com/en/2.1/topics/testing/tools/#django.test.TestCase.setUpTestData
> [2]
> https://github.com/charettes/django/compare/setuptestdata...charettes:testdata
> [3] https://github.com/charettes/django-testdata
> [4] https://pypi.org/project/django-testdata/
>
> --
> 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
> 

Re: Password reset emails in combination with click tracking do not work with Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave

[Adam Johnson]

It sounds to me that this your email provider rewriting the link to go
through their tracking site, and Safari now blocks the tracking site. I
don't see how Django can do anything around this - the "internal token
redirect" (which I guess means a Django generated redirect from one page to
another on your site) is going to be after going through the tracking site,
no?

On Thu, 22 Nov 2018 at 09:51, Mat Gadd  wrote:

> Hi all,
>
> I raised a ticket  regarding
> this and was directed here to discuss the topic. The summary is that the
> combination of using click-tracking redirects (which are popular with a
> variety of email providers) with the Django contrib.auth password reset
> views does not work in Safari on macOS and iOS as of the latest major
> versions.
>
> It took me quite a long time to work out what was happening, so I wanted
> to at least raise a ticket where other people might find it, but was also
> hoping to start a discussion around how else the problem could be
> mitigated. An option to disable the internal token redirect might be
> useful, but that then re-opens the token up to being leaked via the
> HTTP_REFERER header.
>
> Regards,
>  - Mat
>
> --
> 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/20d7a1d1-9c37-44df-8d6f-577f55727efc%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0-LCdQwnh5J9jq85haQ8bP6PhPcs-Y2B60OKw3C5A2cw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Intended effect of returning None from ManifestFilesMixin.file_hash

[Adam Johnson]

That does seem like an unintentional bug, since the code is forming a
string under the condition "if file_hash is not None:".

On Sun, 25 Nov 2018 at 03:26, Richard Campen 
wrote:

> Hello
>
> I am currently looking at implementing a custom file hashing function when
> using the ManifestFilesMixin class to provide white list based file hashing
> of static files.
>
> In the process I have found what seems to be an unintended result of
> returning `None` from a custom `file_hash()` function when using the mixin.
> Looking at the original ticket
> 
> that resulted in the refactoring of the file hashing into it's own function
> (for the explicit intention of enabling custom algorithms when using the
> mixin) there is no indication of intent for the current behaviour.
>
> Essentially, when returning a string from a custom` file_hash()`
> implementation, the resulting file name is
> `..` as expected, whereas returning `None`
> results in `None.`
>
> The fact that the string `None` appears in the file name seems
> undesirable, and the fact it occurs without a preceding `.` (inconsistent
> with the filename structure when a string is returned) suggests to me it is
> unintentional.
>
> I have my own fix to this locally that leaves the file name untouched if
> `file_hash()` returns `None`. Before going through the process of starting
> a ticket etc. I was curious if anyone had any thoughts on the intent of
> injecting `None` into the file name. Bug or feature.
>
> Cheers
> Richard
>
> --
> 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/050868a3-b941-4cd1-b4e4-7b1b6329d8b4%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2rAwHYy5KZw_t4Lrzz3zaAw1cwOvFoJMW%3DCPsw4U%3D6hQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.