Re: Proposing the removal of Oracle from the Django supported backend databases
Hello, when I got started with Django more than 10 years ago, I had inherited a legacy project with an Oracle database for porting from PHP to Python. It might also have worked out well if Oracle support had been a 3rd party package, but I can say for sure that Oracle being a core feature of Django was a huge help in getting me started. I'm aware that this is a weak argument from unfortunately a code non-contributor (or indirect contributor at best) who is not shouldering the work and not even using the Oracle backend any more (we migrated to MySQL). But still, I would like to express my opinion that having Oracle in Django core is a worthwhile asset. Best regards, Carsten Am 03.08.23 um 10:25 schrieb Paolo Melchiorre: > Hi all, > I wanted to share the frustration of seeing yet another great new ORM > feature blocked due to Oracle compatibility: > https://github.com/django/django/pull/16417 > > In the past, I too have had to put a lot of effort trying to make a PR > compatible with Oracle, making the overall contributing experience > much less pleasant and holding me back from contributing, especially > in the early days. > > Over the last few months, I've tried to encourage newcomers and young > users to contribute to Django and they almost always ran into the need > to provide compatibility to Oracle, so much so that they eventually > gave up contributing. > > I stress that I am absolutely not criticizing the contributors (very > few) in the community who help overcome the difficulties with Oracle. > > The point is that I think Oracle is a historical anomaly among the > database backends supported by Django because it is the only one that > is not Open Source, it has irrelevant usage numbers (see Django > Developers Survey 2022 Results > https://lp.jetbrains.com/django-developer-survey-2022/#horizontal-bar-chart-862) > and the company that earns from it does not contribute in any way to > its maintenance or support (see Carlton Gibson keynote at PyCon Italia > 2023 https://youtu.be/AHjnGtaWDjU?t=836) > > To add to all this we consider that developing for Oracle is much more > difficult than for the other Open Source databases supported by Django > and above all the new contributors to the ORM have a frustrating > experience and therefore they are less and less. > > I, therefore, suggest that we start a discussion on removing Oracle > from supported databases. > > Ciao, > Paolo -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/199b5a9f-1b10-eb13-68ea-46a66cad609b%40cafu.de.
Re: Proposing the removal of Oracle from the Django supported backend databases
Hi Mariusz, On Thu, Aug 3, 2023 at 8:47 PM Mariusz Felisiak wrote: > I'm quite surprised that you've started a new thread for something that was > already discussed, you could always add a comment to the existing thread e.g. > https://groups.google.com/g/django-developers/c/dg8BUVHKOo4/m/5uFVmdWCAwAJ I was not aware of this thread, thanks for linking it. >> I wanted to share the frustration of seeing yet another great new ORM >> feature blocked due to Oracle compatibility: >> https://github.com/django/django/pull/16417 > I'm not sure how you reached this conclusion. This is not blocked due because > of Oracle compatibility. I will review it and try to merge it before the > Django 5.0 feature freeze. You have to be patient, it has nothing to do with > Oracle It was not my intention to push you into reviewing this PR given how much you already do. But it seems to me that without Oracle compatibility this functionality would have been ready for a long time. However, this reflection of mine was born after seeing the difficulty of the original contributor to add support to Oracle, at the same time I also watch again Carlton's keynote at PyCon Italia 2023 because the videos have recently been published. Lastly, while volunteering at the DSF booth at EuroPython 2023, I happened to meet an Oracle Django developer for the first time, who admitted that he had never contributed to the Oracle backend itself. >> Over the last few months, I've tried to encourage newcomers and young users >> to contribute to Django and they almost always ran into the need to provide >> compatibility to Oracle, so much so that they eventually gave up >> contributing. > Really? Django is not only the ORM. It is easy to demonize Oracle. I'm > working with contributors on daily basis, and don't remember anyone who > would resign because we have builtin Oracle backend. We don't have much more > open tickets in the Oracle backend then in others. The number of unsupported > features is similar to SQLite or MySQL. In my personal experience, the people I collaborate with at work or meet in the local communities where I go to talk about Django all have experience with Open Source databases and none have ever worked with Oracle, which makes it very difficult for them to try to contribute in Django's ORM why should they ensure compatibility for this DB without ever having seen it. >> The point is that I think Oracle is a historical anomaly among the database >> backends supported by Django because it is the only one that is not Open >> Source, it has irrelevant usage numbers > It's not an anomaly. Oracle support was a conscious decision, keeping the ORM > features Oracle-compatible is a good battlefield, that helps keeping the ORM > friendly for 3rd-party database backends as we have more feature flags and > hooks for custom behaviors. I think this would be the same if the Oracle backend was a third-party package, perhaps maintained by the same company >> ... and the company that earns from it does not contribute in any way to its >> maintenance or support > Should be also drop support for Windows for exactly the same reason? > (rhetorical question) I don't know, I haven't used Windows since 2000 :-) Anyway, tornado to talk about Database, SQL Server is a third-party package >> I, therefore, suggest that we start a discussion on removing Oracle from >> supported databases. > This was already discussed. I'm still strongly against it. Thank you for your point of view, and also for all the extra work you do to help Django contributors who are having trouble making their functionality compatible with Oracle. I reiterate that my only intention was to understand if I were the only one to have this point of view without wanting to criticize anyone's work or past choices, things simply change in the field of information technology and choices could be reviewed after years. Ciao, Paolo -- Paolo Melchiorre https://www.paulox.net -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx6VjKOBpUtujXh-SJ3wjfO3sfLz4ekMRukiBNfy2W-FMw%40mail.gmail.com.
Re: Feature Request: Allow Serialize Foreign Keys as Ids
You are correct state_id is not a field on the model, state is, and using “
state” in the field lists works.
I would like to propose that if ‘state_id’ is a valid property on the
queryset (and in the database) that is should be serialized.
It is my preference that a serialized JSON property (to be consumed in a
strongly typed language) is reserved for a specific type. I realize Django
will determine that `state: int` is an Int and it needs to do a FK lookup
and populate that property with the state model but a strongly typed
language does not have that ability to determine between two types nor does
it have the ability to requery. So my preference when I consume JSON
response into my apps is to reserve state: { title: str, etc...} to an
object representing State model and use state_id: int wherever I just need
the Integer.
While I understand that this is my personal preference I think it is
reasonable to request that if QuerySet.state_id returns a valid value then
it should also be capable of being serialized as well.
On Thursday, August 3, 2023 at 9:46:27 PM UTC-4 Curtis Maloney wrote:
> Hi Mike,
>
> On Fri, 4 Aug 2023, at 06:03, Ryan Gartin wrote:
>
> I came across this issue calling the following and FK fields with _id are
> ignored:
> serialize('json', , fields=['title', 'state_id']).
>
>
> I think the problem you've run into here is "state_id" is not a Field on
> your model; it's where the raw PK value for your ForeignKey is stored.
>
> I've just double checked the code for serialize, and I'm pretty sure the
> default behavior for a ForeignKey field _is_ _already_ to output the PK
> value.
>
> What happens in your code if you put "state" instead of "state_id" in the
> field list?
>
> --
> Curtis
>
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/a88b978f-0d9f-4ac9-a932-41de251dba64n%40googlegroups.com.
