On 01/09/2016 09:29 AM, Shai Berger wrote:
> There are two kinds of data migrations, generally speaking.
>
> One is the kind that is needed to facilitate some schema migrations. Changing
> the type of some field, for example, usually involves creating the new field
> (schema migration), transfor
Thanks Marten for replying. Good work over the URL dispatcher, I'm sorry
the deadlines weren't met, but good to see the development still after
that. :)
Himanshu Mishra
On Saturday, January 9, 2016 at 7:59:23 PM UTC+5:30, Marten Kenbeek wrote:
>
> Hi Himanshu,
>
> Last summer I was the only par
I agree! Also, does this already happen for the MySQL backend? MySQL has
the insert on conflict update, that could work the same way.
However, if I'm not wrong, the docs states that the above methods have a
race condition (obvious since right now it does two operations), but if the
code would ac
Thanks for your input everyone.
You convinced me we should with the third option[1] for now.
Markus, nothing prevent us from changing this behavior in the future
if there's a need for it but since this is a regression and we don't have
a clear backward compatible upgrade path defined we should go
On 01/08/2016 05:13 PM, bliyan...@rentlytics.com wrote:
> Postgres 9.5 has added the functionality for UPSERT aka update or
> insert. Any interest in aligning UPSERT on the db layer with the
> get_or_create or update_or_create functionality in django? Sounds like
> my company would be interested
Hello,
On 9 janv. 2016, at 19:51, Shai Berger wrote:
> So, I say, go for option 3. A field defined in a model in app1 takes app-
> relative references in app1.
I agree.
We’re discussing an unintended regression. The discussion shows possible
improvements in this area but the correct course of
Triaged
---
https://code.djangoproject.com/ticket/26024 - ConditionalGetMiddleware's
ETag is broken (accepted)
https://code.djangoproject.com/ticket/26028 - Improve instructions for
overloading Django templates (accepted)
https://code.djangoproject.com/ticket/26030 - Password change, no
Shai, I think I have a viable solution for the the second kind of data
migration your are mentioning.
https://code.djangoproject.com/ticket/26064#ticket
Simon
Le samedi 9 janvier 2016 11:30:01 UTC-5, Shai Berger a écrit :
>
> On Saturday 09 January 2016 04:56:11 'Hugo Osvaldo Barrera' via Django
On Saturday 09 January 2016 00:15:32 Markus Holtermann wrote:
> That's a nice one, Simon.
>
Yep.
[Simon said: 1: error out, 2: take model from child's app; 3: take model from
abstract parent's app]
> tl;dr: I favor 2; am OK with 1 but against 3.
>
But here I no longer agree.
> I was favorin
On Saturday 09 January 2016 04:56:11 'Hugo Osvaldo Barrera' via Django
developers (Contributions to Django itself) wrote:
>
> In my case, once data migrations have run in staging/production, they're
> useless and can be ignored forever, so there's no point in keeping them
> in later squashed migr
Hi Himanshu,
Last summer I was the only participant in GSoC 2015 for Django. I worked on
a complete rewrite/refactor of the URL dispatching framework. I wasn't able
to finish my project at the time due to personal circumstances. Right now
the project is nearing completion, I'm aiming at the nex
Hello people,
I was looking around for some open source organizations in GSoC 2015 list
who were based on Python or Django. I found out that the Django Software
Foundation had participated in it too ! But there are no proposals overview
or code submissions over melange. Most probably it means t
12 matches
Mail list logo
