Re: New contributor

['Adam Johnson' via Django developers (Contributions to Django itself)]

Welcome!

There are many different ways to contribute to Django - the forum,
blogging, translating, documenting, writing code, and more. Our
Contributing Guide can help you get started with many of these:
https://docs.djangoproject.com/en/stable/internals/contributing/

If you’re looking to work with the code base (for documentation or code),
check out the “Advice for New Contributors” section:
https://docs.djangoproject.com/en/stable/internals/contributing/new-contributors/
. Then see if you can work through the “Writing Your First Patch” tutorial:
https://docs.djangoproject.com/en/stable/intro/contributing/ .

If you get stuck or have questions, post back here or in the “Mentorship”
section on the forum:
https://forum.djangoproject.com/c/internals/mentorship/10

Hope that helps,

Adam

On Fri, Jan 20, 2023 at 10:26 PM Muhammad Hassan 
wrote:

> Hi Every One,
> I want to contribute.
> Please assign me a task or issue.
>
> --
> 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/fbcdb59c-f17b-4bb8-8212-ab1d36df7ea4n%40googlegroups.com
> 
> .
>

-- 
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/CAMyDDM3-f%2B4AnDimAE6DHkgPAkYTG1SRbymYSYOcfNoH%3DRXNGg%40mail.gmail.com.

Re: Proposal for an "Age" PostgreSQL ORM function

['Adam Johnson' via Django developers (Contributions to Django itself)]

+1 to what Carlton said. You can make this function in your project like so:

class Age(Func):
function = "AGE"

A Django wrapper would actually be more complicated. You’d need to
understand both the PostgreSQL and Django function docs, and you might not
be sure Django does anything special besides call the SQL function.

On Fri, Jan 20, 2023 at 1:35 PM Carlton Gibson 
wrote:

> From the maintenance perspective, it's not that any one individual
> function is too hard to maintain — it's clearly not.
>
> Rather it's about not adding a million of them — which would add up — and
> in so doing essentially duplicating the entire API offered by databases.
>
> * Each one we add makes the docs longer, and less fun to read. Every user
> has to answer (for each one) "What's this?" and "Is it relevant to me?"
> * Once you get beyond the core functions they impose that cost with less
> and less likelihood of being relevant.
> * And the function wrappers are in the main really quite trivial to add to
> your own project if you want them.
>
> Previous discussions have more or less pointed to the core cases being
> covered, and not adding a whole lot more.
> (There's always the possibility that one extra **is** worth adding, but …)
>
> One question:
>
> > the function wrappers are in the main really quite trivial to add to
> your own project if you want them.
>
> Can we make the docs point this out more clearly?
>
> Like custom fields, custom functions shouldn't be something folks shy away
> from. 🤔
>
> Kind Regards,
>
> Carlton
>
>
>
>
>
> On Friday, 20 January 2023 at 13:44:57 UTC+1 j.bre...@netzkolchose.de
> wrote:
>
>>
>>
>> Am 19.01.23 um 21:14 schrieb Jason Johns:
>> > the AGE function takes in two timestamps and returns an interval.  You
>> > can do this in python by subtracting two date/datetime objects and
>> > getting a timedelta.  what would the difference be to kick this out to
>> > the db?
>>
>> I'd say thats mainly about performance - the DB can almost almost always
>> calculate things much more efficiently, eg. for AGE with table data:
>> - less datapoints to be moved to client side (should run ~2x faster
>> here, if the mangling of datetime and range type is equally expensive)
>> - Ideally the db has a fast impl for the function, thus the calculation
>> loop would also run faster than in python / on django side.
>>
>> Since I have not benchmarked AGE this is all speculative (TM), but there
>> is a good chance to get at least a 2x faster processing.
>>
>> Furthermore this is also about SQL realms vs. client roundtrips &
>> deduplication - a value calculated on python side cannot be used in SQL
>> directly anymore, you either need another python roundtrip to calc the
>> values and put it back to DB side or some data duplication on a table
>> (eww, now you've violated the normalization rules).
>>
>> Still all that is not yet a good indicator, whether AGE should be
>> supported natively, as there is more to it from ORM perspective:
>> - Is AGE a vivid use case, does it help django users to get things done?
>> - Whats the testing/maintenance burden of AGE?
>> - How about other DB vendors?
>>
>> Now to the downsides of AGE in postgres itself - it creates a "symbolic"
>> range string in years|months|days, rather than in postgres' standard
>> interval repr. This might create frictions at the interval to timedelta
>> translation in psycopg*, at least needs extensive testing for edge
>> cases, that might occur in that weird "symbolic" notation. That
>> uncertainty is a very bad startpoint for an ORM to get reliable
>> functionality and def. raises the test/maintenance needs just for that
>> AGE function.
>>
>> An in-depth analysis of all these points might reveal, that its more
>> reliable to just use datetime substraction at SQL level. Which is
>> already easy doable and prolly also works with many other DB vendors.
>> Which again somewhat questions the idea for native postgres AGE support.
>>
>> In summary - I am not against an ORM age thingy, still think that a more
>> general impl covering other vendors as well might be more helpful.
>>
>> Cheers,
>> Jerch
>>
>>
>> [*] Again speculative (TM) - I know that Daniele Varrazzo does a really
>> great job in maintaining psycopg and it prolly will just work as
>> expected. It still creates a dependency on a less often used/tested code
>> path, so needs more caution on ORM side.
>>
> --
> 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/a46517dd-a03f-47e6-bdd6-4a052e6bdaecn%40googlegroups.com
> 
> .
>

-- 
You re

Reverse for 'car_details' with arguments '('',)' not found. 1 pattern(s) tried:

[Bipul Dawadi]

  In Views.py def car_details(request, id): redirect_to=1 
single_car = get_object_or_404(Car, pk=id), 
 data = { 'single_car': single_car, # 'url': url, }
 # reverse('single_car', args=(id)) 
 return render(request, 'cars/car_details.html', data)
 In urls.py of my app 
urlpatterns = [ path('', views.cars, name='cars'), 
 path('\/car_details', views.car_details, name='car_details'),]
 and In my templates cars.html
 {% for car in cars %}  {{car.car_title}} 

  {{car.state}}, {{car.city}}  
{% endfor %} 
when i tried to call this car_details.html with urls function it show me 
this error Reverse for 'car_details' with arguments '('',)' not found. 1 
pattern(s) tried: I also tried with reverse function it doesnot work,How 
can I solve this error  

-- 
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/558ec0a3-0500-451a-bb5d-e31de430dfd2n%40googlegroups.com.