Re: Removing Oracle from Django core in 3.0

[gg wwk]

Firstly, greetings everyone I'm new here but I am looking to learn and use
Django more so...

I see the edge cases being a issue but I am for Oracle going out of core.
And in order to maintain and/or expand MySQL support  how is the the
implementation of MariaDB  going so far?

I quick glance revealed this much:
https://github.com/django/django/search?q=mariadb_q=mariadb

Thanks,
gwk

On Mon, Nov 26, 2018 at 10:32 PM Dan Davis  wrote:

>
> Another related question -
> https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/#testing-other-python-versions-and-database-backends
> provides some terse advice for running the unit tests with different
> backends.   Is that essentially what is happening with a test like
> https://djangoci.com/job/django-oracle-1.11/, or is it more specific?
>
> On Monday, November 26, 2018 at 2:41:32 PM UTC-5, Tim Graham wrote:
>>
>> That's the query I would use. The 'oracle' keyword might not be assigned
>> completely but you can scan through all the "Database layers" tickets
>> fairly easily and add it to any that are missing.
>>
> --
> 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/5bfa1fe2-38b2-4086-bc57-f9badec93489%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/CAKQ93yuqg5UydMA083Bf-xvOt6OEMKe0nQW1EKPKdk%2Bb6RG%3DEg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing Oracle from Django core in 3.0

[Dan Davis]

Another related question - 
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/#testing-other-python-versions-and-database-backends
 
provides some terse advice for running the unit tests with different 
backends.   Is that essentially what is happening with a test 
like https://djangoci.com/job/django-oracle-1.11/, or is it more specific?

On Monday, November 26, 2018 at 2:41:32 PM UTC-5, Tim Graham wrote:
>
> That's the query I would use. The 'oracle' keyword might not be assigned 
> completely but you can scan through all the "Database layers" tickets 
> fairly easily and add it to any that are missing.
>

-- 
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/5bfa1fe2-38b2-4086-bc57-f9badec93489%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing Oracle from Django core in 3.0

[Tim Graham]

That's the query I would use. The 'oracle' keyword might not be assigned 
completely but you can scan through all the "Database layers" tickets 
fairly easily and add it to any that are missing.

On Monday, November 26, 2018 at 12:25:06 PM UTC-5, Dan Davis wrote:
>
> Related question - how would I search for Oracle specific issues.   I 
> found this query:
>
>
> https://code.djangoproject.com/query?status=assigned=new=~oracle=Database+layer+(models%2C+ORM)=id=summary=status=component=owner=type=version=1=id
>
> However, I'm not sure how much I can rely on the keywords.
>

-- 
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/0baf8e65-562b-428a-ac70-3db0e92c8dac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Moving database backends out of the core

[Dan Davis]

I think this would only work if most database specific backends were 
maintained by the djangoproject itself, allowing for integration tests that 
test compatibility.
To my mind, a strong ORM to backend API is a great thing, but we also need 
stronger backend integration tests.

-- 
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/23759c70-4148-4ac7-8dfa-ca97f1dae97d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing Oracle from Django core in 3.0

[Dan Davis]

Related question - how would I search for Oracle specific issues.   I found 
this query:

https://code.djangoproject.com/query?status=assigned=new=~oracle=Database+layer+(models%2C+ORM)=id=summary=status=component=owner=type=version=1=id

However, I'm not sure how much I can rely on the keywords.

-- 
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/affc60fa-b182-4767-aae8-086f5ba8fe4a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Moving database backends out of the core

[Michael Manfre]

On Mon, Nov 26, 2018 at 10:49 AM Tom Forbes  wrote:

> On your point about non-standard backends, maybe we should focus on making
> it easier to add third party backends and standardize some of the
> internals? We could treat the backend as external (i.e no special hacks for
> them) but keep them in the Django package. If we make the interfaces a bit
> more abstract it would be a lot easier for these backends to exist without
> hacks perhaps.
>

Over the past several years when I first started this thread, the API has
improved and these types of improvements reduced the need to monkey patch
or completely rewrite bits of the ORM in django-mssql. Continuing to
move/keep any DB specific hacks out of the ORM and in to their respective
backend makes Django friendlier for 3rd party database backends. The API is
still deemed internal and if you push for a more official database backend
API, I suggest clearly stating that it will still be exempt from the
standard deprecation policy. There was a lot of strong opposition to
changing that policy in the past.

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

Re: Moving database backends out of the core

[Tom Forbes]

I see where you are coming from, but I'm not sure it will have the intended
effect. One of the great things about Django is that for the most part
database features work everywhere. If we split them out there will be more
innovation, sure, but we may loose the 'database transparency' we currently
have leading to inconsistencies.

It may also be harder to coordinate changes across databases that require
changes to core.

On your point about non-standard backends, maybe we should focus on making
it easier to add third party backends and standardize some of the
internals? We could treat the backend as external (i.e no special hacks for
them) but keep them in the Django package. If we make the interfaces a bit
more abstract it would be a lot easier for these backends to exist without
hacks perhaps.

As with everything, it's a trade off. I'm not sure there is a clear answer
or better solution for all cases than we currently have.

On Mon, 26 Nov 2018, 08:57 Johannes Hoppe  I want to address a completely different point, and that *innovation*. I
> believe that 3rd party backends could lead to more innovation in the Django
> ORM.
> Currently if you want to introduce a new feature for your database, you
> are faced with a lot of complications added by databases you might not be
> familiar with. Furthermore you might be requested to makes those features
> available for databases you haven't used before. This drastically increases
> the bar for contributing innovative new features. As an example, I wanted
> to add database defaults for Postgres and multiple insert return values. I
> finished the postgres feature in 2 sprints, but it took me another half
> year to implement the same for Oracle. Mainly because I never used Oracle
> before.
>
> Beyond that I see that the sheer effort to remove the backends from core
> could lead to better design. We currently assume that all databases speak
> some flavor of Std SQL, which isn't even true for the currently supported
> databases and certainly not for the verify famous mongo-db backend.
>
> In conclusion, more separation will lead to more diversity. But that is a
> good thing, something to embrace and can lead to great results. I would
> even go as far as to kick Postgres out too, contrary to what Florian
> suggested. I believe Postgres could benefit from a separate package.
>
> I think Django has the best ORMs and us being able to make changes and
> innovate, can ensure that this is still true a decade from now.
>
> On Friday, March 15, 2013 at 3:29:29 PM UTC+1, VernonCole wrote:
>>
>> My organization just hit a use case where we need MS-SQL support.
>>
>>  I am jumping on board, so there are at least two of us who can do
>> maintenance.
>>
>> I must say that I would prefer quasi-supported status (akin to admin
>> and geodjango) rather than actually being in the core.  I think it would
>> be a better fit for most situations.  We will always be a small minority
>> of
>> django users.  I would just like some assurance that pull requests needed
>> to provide good hook support for external database backends got prompt
>> attention from the core developers.
>> --
>> Vernon Cole
>>
>> On Thursday, March 7, 2013 6:46:18 PM UTC+1, Jacob Kaplan-Moss wrote:
>>>
>>> On Wed, Mar 6, 2013 at 3:22 AM, Marc Tamlyn  wrote:
>>> > I don't know why Oracle is included and MSSQL is not [...]
>>>
>>> It's essentially because a group of people made a concerted effort to
>>> get the Oracle backend up to snuff (around the 1.0 timeline, I think?)
>>> and then committed to maintaining it. Lately the original people who'd
>>> made that commitment have dropped off a bit, but there's always been
>>> enough attention to keep it up to date.
>>>
>>> If someone -- preferably a group -- stepped up and committed to
>>> keeping a MSSQL backend up-to-date in core, I'd be +1 on merging it
>>> and giving those people commit access to keep it up to date.
>>>
>>> [This is me speaking personally, not as a BDFL. It'd have to be a
>>> discussion, not just my fiat.]
>>>
>>> Jacob
>>>
>> --
> 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/978f91f8-709a-48dc-b2e2-b940e19a9f7f%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 

Re: Removing Oracle from Django core in 3.0

[Tom Forbes]

Indeed, the initial setup of the database takes a horrendous amount of time
(like 30 minutes to init an empty database!).

On Mon, 26 Nov 2018, 14:12 Johannes Hoppe  To quote the documentation:
> https://github.com/orf/django-docker-box/blob/85780dcc81d62a4c0c1142b45eb69e825d97b074/README.md#oracl
> e
>
>
> "As usual Oracle is a bit more complex to set up.” ;)
>
>
> --
> Johannes Hoppe
>
> www.johanneshoppe.com
>
> Want to chat? Let's get a coffee!
> https://calendly.com/codingjoe/coffee
>
> Lennéstr. 19
> 14469 Potsdam
>
> USt-IdNr.: DE284754038
> On 26. Nov 2018, 14:55 +0100, charettes , wrote:
>
> I haven't tried it out for Oracle yet but Tom Forbes' django-docker-box
> seems to make it a not-too-painful process[0]
>
> Simon
>
> [0] https://github.com/orf/django-docker-box#oracle
>
> Le lundi 26 novembre 2018 04:05:41 UTC-5, Johannes Hoppe a écrit :
>>
>>
>> On Monday, November 26, 2018 at 9:49:46 AM UTC+1, Florian Apolloner
>> wrote:
>>>
>>> Hi,
>>>
>>> I personally agree with Mariusz here. Oracle might have it's own quirks,
>>> but the same could be said for any database. Taking my experience with the
>>> ORM into account I do not think that Oracle requires much more work (if at
>>> all) than any other database. I think in the end it does not matter whether
>>> one works around the limitations/features of Oracle or MySQL. All in all I
>>> think having Oracle is a good thing because databases like MSSQL and
>>> Informix/DB2 quite often behave similar to Oracle and just narrowing the
>>> core scope to MySQL/Pg/Sqlite might lead to a kind of tunnel vision.
>>>
>>> Granted, Oracle might be a bit harder to install; but with the developer
>>> VMs and docker containers that argument doesn't really hold either imo.
>>>
>> There is not official container and the one you can build from their
>> repo, didn't work for me. Furthermore you need to register with oracle and
>> give them your Phone number, just to download the python library bindings.
>> So it is somewhat harder than others ;)
>>
>>>
>>> Cheers,
>>> Florian
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/dg8BUVHKOo4/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/ee9fa331-1606-48fb-9362-e86cd9f3c9ae%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/d638aa8b-c10a-4c3c-b6d4-a687d3d9d979%40Spark
> 
> .
> 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/CAFNZOJNC_WNqOuymisOD_6tWNSSxu3yoKoJCt0KiugFX77Tm7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Migration strategy for proxy model permissions to use their own content type

[Arthur Rio]

Hi all,

I have been working on a 9 years old ticket that I'd like to close once and 
for all. The outstanding question is about the migration path to choose in 
order to update existing proxy model permissions. I have explained three 
different approaches I can think of in the pull 
request: https://github.com/django/django/pull/10381#issuecomment-435534644. 

I have implemented the first option and wrote the release notes explaining 
what to expect for users upgrading: 
https://github.com/django/django/pull/10381/files#diff-1f22a5c1d6164c6de8defb36f3829138.

Carlton, who has been the main reviewer, suggested to contact the mailing 
list for further review in order to catch any red flag and make sure we 
have general consensus on the chosen approach. 

Regards.

Arthur

-- 
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/f3298dbb-e072-4815-944c-2250d0b4d3a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing Oracle from Django core in 3.0

[Johannes Hoppe]

To quote the documentation: 
https://github.com/orf/django-docker-box/blob/85780dcc81d62a4c0c1142b45eb69e825d97b074/README.md#oracle

"As usual Oracle is a bit more complex to set up.” ;)


--
Johannes Hoppe

www.johanneshoppe.com

Want to chat? Let's get a coffee!
https://calendly.com/codingjoe/coffee

Lennéstr. 19
14469 Potsdam

USt-IdNr.: DE284754038
On 26. Nov 2018, 14:55 +0100, charettes , wrote:
> I haven't tried it out for Oracle yet but Tom Forbes' django-docker-box seems 
> to make it a not-too-painful process[0]
>
> Simon
>
> [0] https://github.com/orf/django-docker-box#oracle
>
> Le lundi 26 novembre 2018 04:05:41 UTC-5, Johannes Hoppe a écrit :
> >
> > On Monday, November 26, 2018 at 9:49:46 AM UTC+1, Florian Apolloner wrote:
> > > Hi,
> > >
> > > I personally agree with Mariusz here. Oracle might have it's own quirks, 
> > > but the same could be said for any database. Taking my experience with 
> > > the ORM into account I do not think that Oracle requires much more work 
> > > (if at all) than any other database. I think in the end it does not 
> > > matter whether one works around the limitations/features of Oracle or 
> > > MySQL. All in all I think having Oracle is a good thing because databases 
> > > like MSSQL and Informix/DB2 quite often behave similar to Oracle and just 
> > > narrowing the core scope to MySQL/Pg/Sqlite might lead to a kind of 
> > > tunnel vision.
> > >
> > > Granted, Oracle might be a bit harder to install; but with the developer 
> > > VMs and docker containers that argument doesn't really hold either imo.
> > There is not official container and the one you can build from their repo, 
> > didn't work for me. Furthermore you need to register with oracle and give 
> > them your Phone number, just to download the python library bindings. So it 
> > is somewhat harder than others ;)
> > >
> > > Cheers,
> > > Florian
> --
> You received this message because you are subscribed to a topic in the Google 
> Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/django-developers/dg8BUVHKOo4/unsubscribe.
> To unsubscribe from this group and all its topics, 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/ee9fa331-1606-48fb-9362-e86cd9f3c9ae%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/d638aa8b-c10a-4c3c-b6d4-a687d3d9d979%40Spark.
For more options, visit https://groups.google.com/d/optout.

Re: Removing Oracle from Django core in 3.0

[charettes]

I haven't tried it out for Oracle yet but Tom Forbes' django-docker-box 
seems to make it a not-too-painful process[0]

Simon

[0] https://github.com/orf/django-docker-box#oracle

Le lundi 26 novembre 2018 04:05:41 UTC-5, Johannes Hoppe a écrit :
>
>
> On Monday, November 26, 2018 at 9:49:46 AM UTC+1, Florian Apolloner wrote:
>>
>> Hi,
>>
>> I personally agree with Mariusz here. Oracle might have it's own quirks, 
>> but the same could be said for any database. Taking my experience with the 
>> ORM into account I do not think that Oracle requires much more work (if at 
>> all) than any other database. I think in the end it does not matter whether 
>> one works around the limitations/features of Oracle or MySQL. All in all I 
>> think having Oracle is a good thing because databases like MSSQL and 
>> Informix/DB2 quite often behave similar to Oracle and just narrowing the 
>> core scope to MySQL/Pg/Sqlite might lead to a kind of tunnel vision.
>>
>> Granted, Oracle might be a bit harder to install; but with the developer 
>> VMs and docker containers that argument doesn't really hold either imo.
>>
> There is not official container and the one you can build from their repo, 
> didn't work for me. Furthermore you need to register with oracle and give 
> them your Phone number, just to download the python library bindings. So it 
> is somewhat harder than others ;)
>
>>
>> Cheers,
>> Florian
>>
>

-- 
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/ee9fa331-1606-48fb-9362-e86cd9f3c9ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Reports - November 2018

[Tim Graham]

Week ending November 24, 2018

Triaged

---

https://code.djangoproject.com/ticket/29966 - Add test coverage for 
BaseHandler's "The view didn't return an HttpResponse object." error 
(accepted)

https://code.djangoproject.com/ticket/29977 - Allow customizing AccessMixin 
redirect (needsinfo)

https://code.djangoproject.com/ticket/29981 - "Please correct the error 
below." (with no errors displayed) when changing an inline that has a 
one-to-one relation to the parent that uses to_field (accepted)

Reviewed/committed

--

https://github.com/django/django/pull/10033 - Fixed #29478 -- Added support 
for mangled names to @cached_property.

https://github.com/django/django/pull/10385 - Refs #29722 -- Added 
introspection of partitions for PostgreSQL.

https://github.com/django/django/pull/10661 - Fixed #29961 -- Made 
RelatedFieldWidgetWrapper hide related item links if wrapping a hidden 
widget.

https://github.com/django/django/pull/10652 - Fixed #29282 -- Prevented 
some admin checks from crashing with TypeError.
https://github.com/django/django/pull/10645 - Fixed #29953 -- Added CSS 
class to column headers in tabular inlines.

-- 
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/4561874c-6be8-4920-973b-7f027ceffde8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing Oracle from Django core in 3.0

[Jani Tiainen]

Johannes Hoppe  kirjoitti ma 26. marrask. 2018 klo
11.05:

>
> On Monday, November 26, 2018 at 9:49:46 AM UTC+1, Florian Apolloner wrote:
>>
>> Hi,
>>
>> I personally agree with Mariusz here. Oracle might have it's own quirks,
>> but the same could be said for any database. Taking my experience with the
>> ORM into account I do not think that Oracle requires much more work (if at
>> all) than any other database. I think in the end it does not matter whether
>> one works around the limitations/features of Oracle or MySQL. All in all I
>> think having Oracle is a good thing because databases like MSSQL and
>> Informix/DB2 quite often behave similar to Oracle and just narrowing the
>> core scope to MySQL/Pg/Sqlite might lead to a kind of tunnel vision.
>>
>> Granted, Oracle might be a bit harder to install; but with the developer
>> VMs and docker containers that argument doesn't really hold either imo.
>>
> There is not official container and the one you can build from their repo,
> didn't work for me. Furthermore you need to register with oracle and give
> them your Phone number, just to download the python library bindings. So it
> is somewhat harder than others ;)
>
>>
I've very successfully built docker images from Oracle official repo
without any major problems.

Also since cx_Oracle 6 you can build db api bindings without oracle sdk
libraries with simple pip install. Using those though requires client libs.

Not sure about registration process and is it needed for instant client or
xe version.


>> Cheers,
>> Florian
>>
> --
> 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/be871f78-76b7-4c52-8172-748248347b82%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/CAHn91ocaJHSSNKM2NB_PAEHude1vyb2apS0n3L9-E-vJecmvsQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Mat Gadd]

Ah, I forgot to include it here, sorry – it's on the ticket linked in my 
original message:

[…] "Protection Against First Party Bounce Trackers" feature of Safari on 
macOS and iOS, as ​described on the WebKit blog 
.

On Monday, 26 November 2018 09:29:02 UTC, Florian Apolloner wrote:
>
>
>
> On Monday, November 26, 2018 at 10:28:07 AM UTC+1, Mat Gadd wrote:
>>
>> Florian, it's not strictly an "internal redirect on a page", but the 
>> combination of being bounced from a different domain to our site, and their 
>> our site immediately performing its own redirect. If the links were 
>> directly to our server, I don't believe this issue would occur.
>>
>
> Interesting, are there any docs on this feature? 
>

-- 
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/64c1fb0a-acc9-4d8a-be70-08e2b3b4a666%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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]

On Monday, November 26, 2018 at 10:28:07 AM UTC+1, Mat Gadd wrote:
>
> Florian, it's not strictly an "internal redirect on a page", but the 
> combination of being bounced from a different domain to our site, and their 
> our site immediately performing its own redirect. If the links were 
> directly to our server, I don't believe this issue would occur.
>

Interesting, are there any docs on this feature? 

-- 
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/ad67e580-bbb8-4cc3-b1b1-1dc8ccf3a87b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Mat Gadd]

Hi both,

Adam, you're right that the email provider is rewriting the URLs to point 
to their server which then redirects to our site. The contrib.auth module 
then performs *another* redirect which appears to cause the privacy feature 
to kick in. If Django didn't perform a redirect then it would work as 
expected. As-is, the cookie that is attempted to be set before the redirect 
is thrown away by Safari and the user sees a message that their token is 
invalid.

Florian, it's not strictly an "internal redirect on a page", but the 
combination of being bounced from a different domain to our site, and their 
our site immediately performing its own redirect. If the links were 
directly to our server, I don't believe this issue would occur.

Regards,
 - Mat

On Sunday, 25 November 2018 20:37:27 UTC, Florian Apolloner wrote:
>
> 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/338f251c-c4e6-441e-a877-641c86974ffe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing Oracle from Django core in 3.0

[Johannes Hoppe]

Hahaha, yes kind of :P
If they become a corporate sponsor it shut up immediately ;)

On Monday, November 26, 2018 at 9:08:13 AM UTC+1, Carlton Gibson wrote:
>
> Hi Joe! 
>
> On 26 Nov 2018, at 09:05, Johannes Hoppe  > wrote:
>
> I don't mind putting in extra work for an open source database. For a 
> private corp that makes 4bn in revenue... not so much. 
>
>
> Is the issue “How to squeeze money out of Oracle?” — On that, did anyone 
> try asking? 
> (I do feel that sentiment too.) 
>
> C.
>

-- 
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/e745b5fe-ac1c-4cd7-bfc5-450d0e4920b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing Oracle from Django core in 3.0

[Johannes Hoppe]

On Monday, November 26, 2018 at 9:49:46 AM UTC+1, Florian Apolloner wrote:
>
> Hi,
>
> I personally agree with Mariusz here. Oracle might have it's own quirks, 
> but the same could be said for any database. Taking my experience with the 
> ORM into account I do not think that Oracle requires much more work (if at 
> all) than any other database. I think in the end it does not matter whether 
> one works around the limitations/features of Oracle or MySQL. All in all I 
> think having Oracle is a good thing because databases like MSSQL and 
> Informix/DB2 quite often behave similar to Oracle and just narrowing the 
> core scope to MySQL/Pg/Sqlite might lead to a kind of tunnel vision.
>
> Granted, Oracle might be a bit harder to install; but with the developer 
> VMs and docker containers that argument doesn't really hold either imo.
>
There is not official container and the one you can build from their repo, 
didn't work for me. Furthermore you need to register with oracle and give 
them your Phone number, just to download the python library bindings. So it 
is somewhat harder than others ;)

>
> Cheers,
> Florian
>

-- 
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/be871f78-76b7-4c52-8172-748248347b82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Moving database backends out of the core

[Johannes Hoppe]

I want to address a completely different point, and that *innovation*. I 
believe that 3rd party backends could lead to more innovation in the Django 
ORM.
Currently if you want to introduce a new feature for your database, you are 
faced with a lot of complications added by databases you might not be 
familiar with. Furthermore you might be requested to makes those features 
available for databases you haven't used before. This drastically increases 
the bar for contributing innovative new features. As an example, I wanted 
to add database defaults for Postgres and multiple insert return values. I 
finished the postgres feature in 2 sprints, but it took me another half 
year to implement the same for Oracle. Mainly because I never used Oracle 
before.

Beyond that I see that the sheer effort to remove the backends from core 
could lead to better design. We currently assume that all databases speak 
some flavor of Std SQL, which isn't even true for the currently supported 
databases and certainly not for the verify famous mongo-db backend.

In conclusion, more separation will lead to more diversity. But that is a 
good thing, something to embrace and can lead to great results. I would 
even go as far as to kick Postgres out too, contrary to what Florian 
suggested. I believe Postgres could benefit from a separate package.

I think Django has the best ORMs and us being able to make changes and 
innovate, can ensure that this is still true a decade from now.

On Friday, March 15, 2013 at 3:29:29 PM UTC+1, VernonCole wrote:
>
> My organization just hit a use case where we need MS-SQL support. 
>
>  I am jumping on board, so there are at least two of us who can do
> maintenance. 
>
> I must say that I would prefer quasi-supported status (akin to admin 
> and geodjango) rather than actually being in the core.  I think it would 
> be a better fit for most situations.  We will always be a small minority of
> django users.  I would just like some assurance that pull requests needed
> to provide good hook support for external database backends got prompt 
> attention from the core developers.
> --
> Vernon Cole
>
> On Thursday, March 7, 2013 6:46:18 PM UTC+1, Jacob Kaplan-Moss wrote:
>>
>> On Wed, Mar 6, 2013 at 3:22 AM, Marc Tamlyn  wrote: 
>> > I don't know why Oracle is included and MSSQL is not [...] 
>>
>> It's essentially because a group of people made a concerted effort to 
>> get the Oracle backend up to snuff (around the 1.0 timeline, I think?) 
>> and then committed to maintaining it. Lately the original people who'd 
>> made that commitment have dropped off a bit, but there's always been 
>> enough attention to keep it up to date. 
>>
>> If someone -- preferably a group -- stepped up and committed to 
>> keeping a MSSQL backend up-to-date in core, I'd be +1 on merging it 
>> and giving those people commit access to keep it up to date. 
>>
>> [This is me speaking personally, not as a BDFL. It'd have to be a 
>> discussion, not just my fiat.] 
>>
>> Jacob 
>>
>

-- 
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/978f91f8-709a-48dc-b2e2-b940e19a9f7f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing Oracle from Django core in 3.0

[Florian Apolloner]

Hi,

I personally agree with Mariusz here. Oracle might have it's own quirks, 
but the same could be said for any database. Taking my experience with the 
ORM into account I do not think that Oracle requires much more work (if at 
all) than any other database. I think in the end it does not matter whether 
one works around the limitations/features of Oracle or MySQL. All in all I 
think having Oracle is a good thing because databases like MSSQL and 
Informix/DB2 quite often behave similar to Oracle and just narrowing the 
core scope to MySQL/Pg/Sqlite might lead to a kind of tunnel vision.

Granted, Oracle might be a bit harder to install; but with the developer 
VMs and docker containers that argument doesn't really hold either imo.

Cheers,
Florian

-- 
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/e15e8a55-f946-4633-90a6-d64fac714265%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing Oracle from Django core in 3.0

[Carlton Gibson]

Hi Joe! 

> On 26 Nov 2018, at 09:05, Johannes Hoppe  > wrote:
> 
> I don't mind putting in extra work for an open source database. For a private 
> corp that makes 4bn in revenue... not so much.

Is the issue “How to squeeze money out of Oracle?” — On that, did anyone try 
asking? 
(I do feel that sentiment too.)

C.

-- 
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/D8BAF003-67FA-4C04-8944-C85D1FC81880%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP

Re: Removing Oracle from Django core in 3.0

[Johannes Hoppe]

On Monday, November 26, 2018 at 8:27:02 AM UTC+1, Mariusz Felisiak wrote:
>
> 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.
>
Haha, sorry, I didn't mean to offend anyone. I hope you can see past my 
poor choice of works. I just noticed that a lot of oracle specific behavior 
is implemented in the base backend, where other backends like MySQL opt to 
override methods to add their db specific behavior. 

>
>>- *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 . 
>
They are actually a lot better maintained then Oracle, which leads me to 
believe it's not used that often. Besides both DBs you mentioned are open 
source. I don't mind putting in extra work for an open source database. For 
a private corp that makes 4bn in revenue... not so much. Maybe a separate 
backend project, would also see more support from Oracle.

>
>>- 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/15a8d317-7749-43f4-a760-e07bb2aab74f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.