Tests failing on postgres 9.6

[André Ericson]

Hi,

I'm having troubles with a couple of tests on postgres 9.6. I've created a 
ticket here: https://code.djangoproject.com/ticket/28234

Because Jenkins is still on 9.5 I would appreciate if someone could try to 
reproduce it on their setup with 9.6.

Thanks.

André Ericson

-- 
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/6c3eaa33-d4c5-448b-81a9-92cd0f059da6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [JOB POST] Django backend developer per Centre Comune di Ricerca - JRC

[Collin Anderson]

(Django-users is a better place for job postings:
https://groups.google.com/d/forum/django-users )

On Tue, May 23, 2017 at 5:17 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello Jorge,
>
> Job postings are inappropriate on this mailing list.
>
> Thanks for your understanding,
>
> --
> Aymeric.
>
>
>
> On 23 May 2017, at 14:54, Jorge Lopez 
> wrote:
>
> We are looking for an experienced Python-Django developer, for a consulting 
> activity at the Joint Research Centre, Ispra site, in the area of Forest 
> management.
> If you are interested, please contact Mr. Matteo Villa - 
> matteo.vi...@finconsgroup.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 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/09446035-2ffe-459f-8212-
> 5a51f02c2486%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/02F78E0F-F4F2-4247-B11F-
> 2CB19D52CAAE%40polytechnique.org
> 
> .
>
> 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/CAFO84S6%3D5zajsHxxC-jxpbe3t9C-iztH4WboWZgHT5zKwqV29A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [JOB POST] Django backend developer per Centre Comune di Ricerca - JRC

[Aymeric Augustin]

Hello Jorge,

Job postings are inappropriate on this mailing list.

Thanks for your understanding,

-- 
Aymeric.



> On 23 May 2017, at 14:54, Jorge Lopez  wrote:
> 
> We are looking for an experienced Python-Django developer, for a consulting 
> activity at the Joint Research Centre, Ispra site, in the area of Forest 
> management.
> If you are interested, please contact Mr. Matteo Villa - 
> matteo.vi...@finconsgroup.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 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/09446035-2ffe-459f-8212-5a51f02c2486%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/02F78E0F-F4F2-4247-B11F-2CB19D52CAAE%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Review of DEP 201 - simplified routing syntax

[Chris Foresman]

Huzzah! Looking forward to the new syntax landing.


On Sunday, May 21, 2017 at 2:56:13 AM UTC-5, Aymeric Augustin wrote:
>
> Hello,
>
> The technical board accepted DEP 201: 
> https://github.com/django/deps/blob/master/accepted/0201-simplified-routing-syntax.rst
>
> Sjoerd has taken the lead on the implementation, please get in touch if 
> you'd like to help!
>
> Thanks,
>
> -- 
> Aymeric.
>
>
>
> On 12 May 2017, at 14:19, Aymeric Augustin  > wrote:
>
> After getting approval from Tom on IRC, I updated the DEP according to my 
> email below: https://github.com/django/deps/pull/41
>
> The next steps are:
>
> - account for any remaining feedback (I feel I made only minor changes 
> compared to the last version, hopefully we can wrap this up quickly now)
> - get approval from the technical board
> - complete the implementation!
>
> -- 
> Aymeric.
>
>
>
> On 12 May 2017, at 12:32, Aymeric Augustin  > wrote:
>
> Hello,
>
> I reviewed the current version of DEP 201 
> 
>  as 
> well as related 
>  
> discussions 
> .
>  
> I took notes and wrote down arguments along the way. I'm sharing them 
> below. It may be useful to add some of these arguments to the DEP.
>
> Sjoerd, Tom, I didn't want to edit your DEP directly, but if you agree 
> with the items marked *[Update DEP]* below I can prepare a PR. I will now 
> take a look at the pull requests implementing this DEP.
>
>
> *Should it live as a third-party package first?*
>
> The original motivation for this DEP was to make Django easier to use by 
> people who aren't familiar with regexes.
>
> While regexes are a powerful tool, notably for shell scripting, I find it 
> counter-productive to make them a prerequisite for building a Django 
> website. You can build a very nice and useful website with models, forms, 
> templates, and the admin, without ever needing regexes — except, until now, 
> for the URLconf!
>
> Since we aren't going to say in the official tutorial "hey install this 
> third-party package to manage your URLs", that goal can only be met by 
> building the new system into Django.
>
> Besides, I suspect many professional Django developers copy-paste regexes 
> without a deep understanding of how they work. For example, I'd be 
> surprised if everyone knew why it's wrong to match a numerical id in a URL 
> with \d+ (answer at the bottom of this email).
>
> Not only is the new system easier for beginners, but I think it'll also be 
> adopted by experienced developers to reduce the risk of mistakes in 
> URLpatterns, which are an inevitable downside of their syntax. Django can 
> solve problems like avoiding \d+ for everyone.
>
> Anecdote: I keep making hard-to-detect errors in URL regexes. The only URL 
> regexes I wrote that can't be replicated with the new system are very 
> dubious and could easily be replaced with a more explicit `if 
> some_condition(request.path): raise Http404` in the corresponding view. I 
> will be happy to convert my projects to the new system.
>
> No progress was made in this area since 2008 because URL regexes are a 
> minor annoyance. After you write them, you never see them again. I think 
> that explains why no popular alternative emerged until now.
>
> Since there's a significant amount of prior art in other projects, a 
> strong consensus on DEP 201 being a good approach, and a fairly narrow 
> scope, it seems reasonable to design the new system directly into Django.
>
>
> *What alternatives would be possible?*
>
> I have some sympathy with the arguments for a pluggable URL resolver 
> system, similar to what I did for templates in Django 1.8. However I don't 
> see this happening any time soon because there's too little motivation to 
> justify the effort. As I explained above, developers tend to live with 
> whatever the framework provides.
>
> Of course, if someone wants to write a fully pluggable URL resolver, 
> that's great! But there's no momentum besides saying that "it should be 
> done that way". Furthermore, adding the new system shouldn't make it more 
> difficult to move to a fully pluggable system. If anything, it will clean 
> up the internals and prepare further work in the area. Some changes of this 
> kind were already committed.
>
> DEP 201 is mostly independent from the problem of allowing multiple views 
> to match the same URL  — 
> that is, to resume resolving URL patterns if a view applies some logic and 
> decides it can't handle a URL. This is perhaps the biggest complaint about 
> the current design of the URL resolver. Solutions include hacking around 
> the current design or changing it fundamentally.

Re: Pre-DEP: Meta.without_primary_key (related to CompositeFields)

[sky . duveen]

Hi Shai,

Thanks for your feedback.

Our 'real' use case, is we have an opaque legacy application that we are 
rewriting in Django.  Adding columns to the tables before we have migrated 
it away from the old application is too risky to do.  I'm at the PyCon2017 
sprins now, and as JKM said it -- having to deal with non-primary-key 
databases might be due to poor life choices :-).  I agree that 
non-uniqueness is an antipattern -- my argument is purely about what 
systems the ORM can interract with/support rather than a feature that 
would/should be used to build new applications/models.  I would hope that 
just like with RawSQL or @csrf_exempt, docs would make that clear.

The huge value we get even without get() or admin/etc is making multi-join 
queries super-easy through the amazing queryset api.  I'm not very familiar 
with the Meta API formalization, so maybe you could elaborate how we would 
use it in such a circumstance -- would I somehow be setting _meta = 
CustomThing() the way we add model managers by setting objects?  Would that 
work on the same backend/db connection?

I originally feared that removing PK would be a complex and burdensome 
project -- which is why I have been content with hacks until now. As I've 
found preliminarily, pk is not as bound as I thought.  This is mostly 
because unsaved model objects are already possible, so a lot of code 
already tests for model.pk before doing something with it.  I was also 
surprised to see, e.g. db.migrations doesn't seem like it would need any 
changes at all.

To go back to use-cases, and the relation to composite fields, a lot of our 
keyless tables seem to be about set membership.  Most of these *are* 
basically elaborate many-to-many intermediate tables, where two (or three) 
fields link several tables together as connected. When we have those 
multiple ids, I have been using models.ForeignObject to make ORM links.

One is something like:

class Vote(models.Model):
   list = models.ForeignKey("List")
   user = models.ForeignKey(User)
   ## a bunch of other fields

   comment = models.ForeignObject("VoteComment", on_delete=models.CASCADE,
  from_fields=['list_id', 'user_id'],
  to_fields=['list_id', 'user_id'])

I know ForeignObject isn't an externally supported API.  However, I think 
it does gesture how composite foreignkeys would emerge from this.  The 
first step is to get rid of places that depend on a (unique and singular) 
primary key -- from there, we can (even slowly) add support for a 
ForeignKey pointing to an object without a primary key but does have the 
same unique_together field coupling.  Once we support ForeignKey() that 
way, we can work on support for inheritance and admin support.

/sky


On Tuesday, May 23, 2017 at 4:31:47 AM UTC-4, Shai Berger wrote:
>
> Hi, 
>
> Thank you for making this suggestion. 
>
> It is my guess that allowing pk-less models will place quite a burden on 
> many 
> parts of Django, which assume a PK exists. There may also be other 
> solutions 
> to the problem you raise -- e.g. changing the legacy table to add a PK, 
> perhaps while providing a pk-less view to any legacy systems which need to 
> access it. 
>
> In general, SQL database tables without any uniqueness guarantee are an 
> antipattern, which I don't believe Django should support. The question 
> remains 
> how much such a feature can be made to contribute towards composite keys. 
>
> All in all, I would like to know more about your use case -- if you are 
> going 
> to have no get/delete, no Admin, no updating save, how exactly are you 
> going 
> to use these models? As you may be aware, since the Meta API 
> formalization, it 
> is possible to create pseudo-models which are good enough for many 
> purposes, 
> without changing Django and with much less strict adherence to "real" 
> models' 
> behavior. Perhaps that is the way to go? 
>
> HTH, 
> Shai. 
>
> On Monday 22 May 2017 21:50:07 sky.d...@moveon.org  wrote: 
> > Hi, 
> > 
> > We have several legacy database tables that don't have primary keys. 
> With 
> > older versions of Django, we've hacked it by lying about a field that 
> was 
> > not a primary key but recent Django versions validate pks more strictly. 
> > 
> > Some (but not all) of our legacy tables have multiple primary keys -- 
> i.e. 
> > are unique only across a few fields.  This harks to the CompositeField 
> work 
> > and discussion [0]. 
> > 
> > But CompositeFields are not enough for us, some of our tables are 
> > essentially append-only, and have no uniqueness constraints across 
> any/all 
> > fields.  It also seems like CompositeField has stalled several times 
> > precisely because we are spiking to a very complex end goal. 
> > 
> > I'd like to propose, both as an incremental step to CompositeFields and 
> > something useful in itself, a model Meta option for 
> `without_primary_key` 
> > -- if Meta.without_primary_key=True then it 

[JOB POST] Django backend developer per Centre Comune di Ricerca - JRC

[Jorge Lopez]

We are looking for an experienced Python-Django developer, for a consulting 
activity at the Joint Research Centre, Ispra site, in the area of Forest 
management.
If you are interested, please contact Mr. Matteo Villa - 
matteo.vi...@finconsgroup.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 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/09446035-2ffe-459f-8212-5a51f02c2486%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pre-DEP: Meta.without_primary_key (related to CompositeFields)

[Shai Berger]

Hi,

Thank you for making this suggestion.

It is my guess that allowing pk-less models will place quite a burden on many 
parts of Django, which assume a PK exists. There may also be other solutions 
to the problem you raise -- e.g. changing the legacy table to add a PK, 
perhaps while providing a pk-less view to any legacy systems which need to 
access it.

In general, SQL database tables without any uniqueness guarantee are an 
antipattern, which I don't believe Django should support. The question remains 
how much such a feature can be made to contribute towards composite keys.

All in all, I would like to know more about your use case -- if you are going 
to have no get/delete, no Admin, no updating save, how exactly are you going 
to use these models? As you may be aware, since the Meta API formalization, it 
is possible to create pseudo-models which are good enough for many purposes, 
without changing Django and with much less strict adherence to "real" models' 
behavior. Perhaps that is the way to go?

HTH,
Shai.

On Monday 22 May 2017 21:50:07 sky.duv...@moveon.org wrote:
> Hi,
> 
> We have several legacy database tables that don't have primary keys. With
> older versions of Django, we've hacked it by lying about a field that was
> not a primary key but recent Django versions validate pks more strictly.
> 
> Some (but not all) of our legacy tables have multiple primary keys -- i.e.
> are unique only across a few fields.  This harks to the CompositeField work
> and discussion [0].
> 
> But CompositeFields are not enough for us, some of our tables are
> essentially append-only, and have no uniqueness constraints across any/all
> fields.  It also seems like CompositeField has stalled several times
> precisely because we are spiking to a very complex end goal.
> 
> I'd like to propose, both as an incremental step to CompositeFields and
> something useful in itself, a model Meta option for `without_primary_key`
> -- if Meta.without_primary_key=True then it would turn off the complaints
> during model validation, etc.  One might object that things like
> get/delete/caching can't work with that model.  However those features
> can't be supported in tables without a primary key anyway.
> 
> Incrementally, after without_primary_key is implemented/supported, we could
> then add features for models without_primary_key but also has a
> Meta.unique_together value across some fields -- i.e. start trying to
> support inheritance and/or ForeignKey references to those tables, building
> up support.
> 
> I've started looking at how deep a change this would be, and believe it's
> pretty tractable.
> Before I get too involved with a DEP and PR, what do people think?
> 
> /sky
> 
> [0] Most recent thread:
> https://groups.google.com/forum/#!searchin/django-developers/primary$20keys
> |sort:date/django-developers/wakEPFMPiyQ/ke5OwgOPAQAJ