Re: Removing Oracle from Django core in 3.0

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

Re: Removing Oracle from Django core in 3.0

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

Re: Removing Oracle from Django core in 3.0

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

Re: Moving database backends out of the core

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

Re: Removing Oracle from Django core in 3.0

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.

Re: Moving database backends out of the core

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

Re: Moving database backends out of the core

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

Re: Removing Oracle from Django core in 3.0

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

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

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:

Re: Removing Oracle from Django core in 3.0

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!

Re: Removing Oracle from Django core in 3.0

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

Re: Fellow Reports - November 2018

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

Re: Removing Oracle from Django core in 3.0

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

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

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,

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

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 >

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

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

Re: Removing Oracle from Django core in 3.0

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

Re: Removing Oracle from Django core in 3.0

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

Re: Moving database backends out of the core

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

Re: Removing Oracle from Django core in 3.0

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

Re: Removing Oracle from Django core in 3.0

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

Re: Removing Oracle from Django core in 3.0

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