Re: Support for `Q` objects in `get_or_create` and `update_or_create`

['Mike Lissner' via Django developers (Contributions to Django itself)]

This is my first message here, and sure enough I'm necromancing this thread 
from 2016!

Below there's a message about how to use Q objects with get_or_create by 
chaining them. This works! But it's not documented. Is it crazy to document 
this?

I think I used the advice in this thread a while back to write some code, 
but when I came upon the code today, it baffled me. I went to the docs, but 
there was no mention of this technique there, and so, here I am again at 
this thread. 

Thanks,

Mike

On Tuesday, August 16, 2016 at 12:27:30 PM UTC-7, Flavio Curella wrote:
>
> It didn't occur to me that it could be done that way. Thanks!
>
> I'm closing the ticket as 'invalid'
>
>
> On Tuesday, August 16, 2016 at 2:03:02 PM UTC-5, charettes wrote:
>>
>> Hi Flavio,
>>
>> Is there a reason we can't document chaining filter() with these methods 
>> when
>> querying with Q() objects?
>>
>> Person.objects.filter(
>> Q(first_name='George') | Q(first_name='Bruce')
>> ).get_or_create(defaults={'last_name': 'Harrison'})
>>
>> If `defaults` was stil only passable as a kwarg this could have worked 
>> but at
>> this point I don't think it's worth the additionnal complexity as there's 
>> no way
>> to introduce a fully backward compatible API without deprecating passing
>> `defaults` as the first arg.
>>
>> Even if we were to agree on a new unlikely used kwarg name to specify the 
>> query
>> object the `(get|update)_or_create` APIs would end up disgressing from 
>> the `filter()`
>> and `get()` ones which is the main objective of this proposed change I 
>> beleive.
>>
>> Simon
>>
>> Le mardi 16 août 2016 13:57:25 UTC-4, Flavio Curella a écrit :
>>>
>>> I'm thinking about adding support for `Q` to `get_or_create` and 
>>> `update_or_create`. I've summarized my thoughts at 
>>> https://code.djangoproject.com/ticket/27070. 
>>>
>>>
>>> I have a couple of unsolved question; the most critical is the one Tim 
>>> raises: if we were to add another keyword argument to those methods, how 
>>> much of an impact will it have? Can we find a name that we can be 
>>> reasonably confident is not used as a model field by anybody (or a _very_ 
>>> small number of users)?
>>>
>>>
>>> Thanks,
>>> –Flavio.
>>>
>>

-- 
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/6c1285c8-94da-49bc-bbbf-c76b8e6cfb3e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support for `Q` objects in `get_or_create` and `update_or_create`

[Adam Johnson]

I think it's perfectly sane to document the filter + get_or_create combo,
feel free to open a ticket and pull request

On 20 February 2018 at 20:26, 'Mike Lissner' via Django developers
(Contributions to Django itself)  wrote:

> This is my first message here, and sure enough I'm necromancing this
> thread from 2016!
>
> Below there's a message about how to use Q objects with get_or_create by
> chaining them. This works! But it's not documented. Is it crazy to document
> this?
>
> I think I used the advice in this thread a while back to write some code,
> but when I came upon the code today, it baffled me. I went to the docs, but
> there was no mention of this technique there, and so, here I am again at
> this thread.
>
> Thanks,
>
> Mike
>
> On Tuesday, August 16, 2016 at 12:27:30 PM UTC-7, Flavio Curella wrote:
>>
>> It didn't occur to me that it could be done that way. Thanks!
>>
>> I'm closing the ticket as 'invalid'
>>
>>
>> On Tuesday, August 16, 2016 at 2:03:02 PM UTC-5, charettes wrote:
>>>
>>> Hi Flavio,
>>>
>>> Is there a reason we can't document chaining filter() with these methods
>>> when
>>> querying with Q() objects?
>>>
>>> Person.objects.filter(
>>> Q(first_name='George') | Q(first_name='Bruce')
>>> ).get_or_create(defaults={'last_name': 'Harrison'})
>>>
>>> If `defaults` was stil only passable as a kwarg this could have worked
>>> but at
>>> this point I don't think it's worth the additionnal complexity as
>>> there's no way
>>> to introduce a fully backward compatible API without deprecating passing
>>> `defaults` as the first arg.
>>>
>>> Even if we were to agree on a new unlikely used kwarg name to specify
>>> the query
>>> object the `(get|update)_or_create` APIs would end up disgressing from
>>> the `filter()`
>>> and `get()` ones which is the main objective of this proposed change I
>>> beleive.
>>>
>>> Simon
>>>
>>> Le mardi 16 août 2016 13:57:25 UTC-4, Flavio Curella a écrit :

 I'm thinking about adding support for `Q` to `get_or_create` and
 `update_or_create`. I've summarized my thoughts at
 https://code.djangoproject.com/ticket/27070.


 I have a couple of unsolved question; the most critical is the one Tim
 raises: if we were to add another keyword argument to those methods, how
 much of an impact will it have? Can we find a name that we can be
 reasonably confident is not used as a model field by anybody (or a _very_
 small number of users)?


 Thanks,
 –Flavio.

>>> --
> 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/6c1285c8-94da-49bc-bbbf-
> c76b8e6cfb3e%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/CAMyDDM2SjuQX3E828znmVaBMFjjP7whBk24qtwpAD29scsuDcA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Thoughts on diff-based migrations with django?

[Andrew Godwin]

Hi,

This was an approach we deliberately avoided during development of the
current migration system - it works poorly with diverging feature branches
and requires that your developers have access to production schema at all
times (and additionally that you don't have divergent production/staging/QA
deploys, like many environments do).

I think it would be a fine addition as an optional third-party tool, but
it's not something that really makes sense to include in Django at this
point I think.

Andrew

On Mon, Feb 19, 2018 at 10:05 PM, djrobstep  wrote:

> Hi all,
>
> Some thoughts on schema migrations that may interest you. By way of
> background, I'm the author of migra (https://github.com/djrobstep/migra),
> a schema comparison/diff tool for Postgres.
>
> I initially wrote this tool because I wanted to be able to generate
> migration scripts automatically, without needing historical migration files.
>
> It means that you can do things like sync your database to your models
> mostly automatically, and also explicitly test for a matching schema.
> Instead of a chain of migration files you only ever need to keep track of
> one, containing any pending changes).
>
> I've used this approach with success on a number of projects now, and it
> seems to work pretty well. I also talked about this approach to migrations
> at the most recent PostgresOpen (https://www.youtube.com/
> watch?v=xr498W8oMRo).
>
> The downside of this approach is that it's slightly more operationally
> complex (you need have a temporary copy of your production schema available
> for comparison purposes, typically a --schema-only dump file) and also that
> it's postgres-only at this point. It's also conceptually quite different to
> the typical Django/Rails style of migrations which represents a barrier to
> entry.
>
> In spite of this, I think doing migrations this way has some compelling
> advantages, that are relevant to users of Django.
>
> I'm interested in your opinions on this topic as Django developers. What
> do you think? Is it something worth offering as an option for managing
> Django migrations? If your feelings are positive, I'm happy to take a look
> at extending the code accordingly.
>
> --
> 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/5f84157b-071e-42c3-90dd-
> 6f9e3df48ab3%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/CAFwN1urzK%3DwWT0SfS32sg_YhcdJnG_2h9Cbp8u2Uouzs6LaWFg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Thoughts on diff-based migrations with django?

[djrobstep]

Yes, this approach certainly doesn't magically solve data migration issues, 
however the data migrations question has been a common one.

The nature of data migrations is that they are very one-off and context 
dependent and so still something you'd need to script up manually. You 
might use the diff tool to generate the migration script required but then 
edit it to add any queries needed for carrying out the data migration.

And doing things this way, there's nothing stopping you continuing to chain 
multiple migration scripts together to support multiple versions in the 
context of a reusable app.

On Tuesday, 20 February 2018 23:27:31 UTC+11, Curtis Maloney wrote:
>
> Hi, 
>
> I must say your idea intrigues me... and I'd certainly like to discuss 
> it further. 
>
> The first thought that comes to mind is how would such a system handle 
> data migrations? 
>
> Being able to leap from one schema state to another is great, buy 
> typically in the life-cycle of a reusable app it's required to also 
> migrate old data into new schema. 
>
> This also happens within project-specific apps. 
>
> -- 
> Curtis 
>
>
> On 02/20/2018 05:05 PM, djrobstep wrote: 
> > Hi all, 
> > 
> > Some thoughts on schema migrations that may interest you. By way of 
> > background, I'm the author of migra 
> > (https://github.com/djrobstep/migra), a schema comparison/diff tool for 
> > Postgres. 
> > 
> > I initially wrote this tool because I wanted to be able to generate 
> > migration scripts automatically, without needing historical migration 
> files. 
> > 
> > It means that you can do things like sync your database to your models 
> > mostly automatically, and also explicitly test for a matching schema. 
> > Instead of a chain of migration files you only ever need to keep track 
> > of one, containing any pending changes). 
> > 
> > I've used this approach with success on a number of projects now, and it 
> > seems to work pretty well. I also talked about this approach to 
> > migrations at the most recent PostgresOpen 
> > (https://www.youtube.com/watch?v=xr498W8oMRo). 
> > 
> > The downside of this approach is that it's slightly more operationally 
> > complex (you need have a temporary copy of your production schema 
> > available for comparison purposes, typically a --schema-only dump file) 
> > and also that it's postgres-only at this point. It's also conceptually 
> > quite different to the typical Django/Rails style of migrations which 
> > represents a barrier to entry. 
> > 
> > In spite of this, I think doing migrations this way has some compelling 
> > advantages, that are relevant to users of Django. 
> > 
> > I'm interested in your opinions on this topic as Django developers. What 
> > do you think? Is it something worth offering as an option for managing 
> > Django migrations? If your feelings are positive, I'm happy to take a 
> > look at extending the code accordingly. 
> > 
> > -- 
> > 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/5f84157b-071e-42c3-90dd-6f9e3df48ab3%40googlegroups.com
>  
> > <
> https://groups.google.com/d/msgid/django-developers/5f84157b-071e-42c3-90dd-6f9e3df48ab3%40googlegroups.com?utm_medium=email_source=footer>.
>  
>
> > 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/62c00b16-a854-4c49-a5c9-7e83dc0c9a2a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Thoughts on diff-based migrations with django?

[djrobstep]

Hi all,

Some thoughts on schema migrations that may interest you. By way of 
background, I'm the author of migra (https://github.com/djrobstep/migra), a 
schema comparison/diff tool for Postgres.

I initially wrote this tool because I wanted to be able to generate 
migration scripts automatically, without needing historical migration files.

It means that you can do things like sync your database to your models 
mostly automatically, and also explicitly test for a matching schema. 
Instead of a chain of migration files you only ever need to keep track of 
one, containing any pending changes).

I've used this approach with success on a number of projects now, and it 
seems to work pretty well. I also talked about this approach to migrations 
at the most recent PostgresOpen (https://www.youtube.com/watch?v=xr498W8oMRo
).

The downside of this approach is that it's slightly more operationally 
complex (you need have a temporary copy of your production schema available 
for comparison purposes, typically a --schema-only dump file) and also that 
it's postgres-only at this point. It's also conceptually quite different to 
the typical Django/Rails style of migrations which represents a barrier to 
entry.

In spite of this, I think doing migrations this way has some compelling 
advantages, that are relevant to users of Django.

I'm interested in your opinions on this topic as Django developers. What do 
you think? Is it something worth offering as an option for managing Django 
migrations? If your feelings are positive, I'm happy to take a look at 
extending the code accordingly.

-- 
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/5f84157b-071e-42c3-90dd-6f9e3df48ab3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Thoughts on diff-based migrations with django?

[Curtis Maloney]

Hi,

I must say your idea intrigues me... and I'd certainly like to discuss 
it further.


The first thought that comes to mind is how would such a system handle 
data migrations?


Being able to leap from one schema state to another is great, buy 
typically in the life-cycle of a reusable app it's required to also 
migrate old data into new schema.


This also happens within project-specific apps.

--
Curtis


On 02/20/2018 05:05 PM, djrobstep wrote:

Hi all,

Some thoughts on schema migrations that may interest you. By way of 
background, I'm the author of migra 
(https://github.com/djrobstep/migra), a schema comparison/diff tool for 
Postgres.


I initially wrote this tool because I wanted to be able to generate 
migration scripts automatically, without needing historical migration files.


It means that you can do things like sync your database to your models 
mostly automatically, and also explicitly test for a matching schema. 
Instead of a chain of migration files you only ever need to keep track 
of one, containing any pending changes).


I've used this approach with success on a number of projects now, and it 
seems to work pretty well. I also talked about this approach to 
migrations at the most recent PostgresOpen 
(https://www.youtube.com/watch?v=xr498W8oMRo).


The downside of this approach is that it's slightly more operationally 
complex (you need have a temporary copy of your production schema 
available for comparison purposes, typically a --schema-only dump file) 
and also that it's postgres-only at this point. It's also conceptually 
quite different to the typical Django/Rails style of migrations which 
represents a barrier to entry.


In spite of this, I think doing migrations this way has some compelling 
advantages, that are relevant to users of Django.


I'm interested in your opinions on this topic as Django developers. What 
do you think? Is it something worth offering as an option for managing 
Django migrations? If your feelings are positive, I'm happy to take a 
look at extending the code accordingly.


--
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/5f84157b-071e-42c3-90dd-6f9e3df48ab3%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/4ef38de9-780c-e2f9-9ce2-5d9621d6bf64%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Regarding GSOC-18

[Tim Graham]

No, we don't have a team of people putting together ideas. If you have some 
experience with Django, you could probably look through Trac tickets and 
put together an original proposal.

On Friday, February 16, 2018 at 4:07:35 PM UTC-5, hardik dadhich wrote:
>
> hello All,
>
> It's my first chance to spend my summertime on GSOC with the contribution 
> to Django.
> I just go through all docs provided on link:* 
> https://code.djangoproject.com/wiki/SummerOfCode2018 
> *
> I want to ask that there are only 3-4 ideas regarding Django or new ideas 
> will be added after some time if it will be added than when?
>  
> thanks for listening 
>
> Regards,
> Hardik dadhich
>
>
>

-- 
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/a7458c2c-b24a-4d64-b804-bb35d4a62125%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code 2018

[Tim Graham]

Hi Priyansh,

Your proposal isn't really detailed enough for me to understand what the 
outcome of your project would be (I haven't watched Russell's talk that you 
linked). What are the "big wins"? There are projects like 
https://github.com/potatolondon/djangae, which allows using Django with 
Google App Engine. Would your project make something like that much 
simpler? You'll have to demonstrate a fairly sophisticated level of 
understanding of Django to convince us that you understand the problems 
well enough to have a reasonable chance of success.

Regarding your proposed schedule, I'm a bit concerned that you'll have 
exams for five weeks of the coding period. Students are expected to average 
30+ hours/week on their projects. Is that feasible while you're studying 
for exams?

On Monday, February 19, 2018 at 1:45:22 PM UTC-5, askpr...@gmail.com wrote:
>
> Hello !
>
> I have drafted a project-proposal for the idea that Russell laid out in 
> his talk at DjangoCon '15. Here's the link to the draft:
>
> https://gist.github.com/priyanshsaxena/4670cae3d03a7b77a16388601c018460
>
> Looking forward to your suggestions on how best to improve this for a 
> concrete GSoC '18 project-proposal.
>
> Regards
> Priyansh
>
> On Wednesday, February 14, 2018 at 3:15:56 AM UTC+5:30, Russell 
> Keith-Magee wrote:
>>
>>
>> Another approach would be to do what I laid out in this talk at DjangoCon 
>> US 2015, following the last Summer of Code student who tackled 
>> (tangentially) this problem. 
>>
>> https://www.youtube.com/watch?v=VgM0qmpHDiE 
>>
>> That is - finish the modifications needed to Django’s core such that an 
>> arbitrary model can register in a way compatible with the Admin and Forms 
>> library. This was one of the reasons given for standardising the meta-model 
>> framework, but didn’t make it into Daniel’s GSoC project, although he *did* 
>> get a proof of concept working that exposed your Gmail inbox in Django’s 
>> admin. 
>>
>> This would allow *any* data backend to expose an interface that is 
>> fundamentally compatible with Django - which, really, just means “I want to 
>> browse my data in the admin” and “I want to display a form for my model”. 
>>
>> It won’t allow an arbitrary ORM query to run against an arbitrary “NoSQL” 
>> backend - but that’s idea was never going to work anyway. But I don’t think 
>> anyone is serious about wanting that, either. All they want is the ability 
>> to integrate a non-SQL data source into their basic Django visualisations. 
>>
>> Yours, 
>> Russ Magee %-) 
>>
>> > On 13 Feb 2018, at 6:48 pm, Curtis Maloney  
>> wrote: 
>> > 
>> > On 02/13/2018 09:23 PM, askpr...@gmail.com wrote: 
>> >> Hello ! 
>> >> What is the policy regarding NoSQL datastores being used as backends ? 
>> I think adding support for something like MongoDB might be good idea. 
>> > 
>> > Could you elaborate on why you think it would be a good idea? 
>> > 
>> > I believe every other time the discussion has come up the following 
>> points have been made. 
>> > 
>> > 1. "NoSQL" is not a DB category, it is an anti-category 
>> > 2. Because of there there is no common data model, or query languages. 
>> > 3. If you limit yourself to just document stores, there is still no 
>> common query language [but this can be hidden by code] 
>> > 4. Document stores are a really really bad fit for the ORM, as it's 
>> designed for the relational model, not document model. 
>> > 5. A better approach would be to develop an ODM, which is sufficiently 
>> compatible with the ORM you can provide similar tools like ModelForms and 
>> ModelAdmin, as well as GCBV. 
>> > 
>> > If I missed anything, I'm sure someone else will remind me. 
>> > 
>> > [Also... why is it always MongoDB, instead of something with a solid 
>> reputation of reliability and performance?] 
>> > 
>> > -- 
>> > 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-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/d9e38eeb-eab1-e0db-8d50-54abe6fb1afd%40tinbrain.net.
>>  
>>
>> > 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