It seems to me that article is written by a guy who has a lot of
knowledge of the database engine and has some issues (mostly) with
Django migrations system. His solution to the problem is to use direct
SQL statements which of course can be more finely controlled than
whatever Django creates
While I agree with some of the author's points, I think a critical piece of
context is that Django migrations are designed for the 90% case - i.e., people
who just want something to work on a small scale and don't need to worry about
many aspects of the database yet.
Like all parts
HI all,
I would suggest reading this interesting article by Daniele Varrazzo
(the maintainer of psycopg2 and creator of psycopg3) on Django
migrations.
It contains some criticisms but I also think some interesting hints
for improving Django ORM :
https://www.varrazzo.com/blog/2020/07/25
ter that
> index creating remain an atomic operation (so, not concurrent) by default.
>
> Best regards,
>
> --
> Aymeric.
>
>
>
>> On 26 Sep 2018, at 07:41, pavel.t...@ <>gmail.com <http://gmail.com/> wrote:
>>
>> Hi,
>>
> default.
>
> Best regards,
>
> --
> Aymeric.
>
>
>
> On 26 Sep 2018, at 07:41, pavel.t...@gmail.com wrote:
>
> Hi,
>
> I found that django migrations don't designed for live updates on large
> tables for postgres, eg. index creation doesn't u
, not concurrent) by default.
Best regards,
--
Aymeric.
> On 26 Sep 2018, at 07:41, pavel.tysla...@gmail.com wrote:
>
> Hi,
>
> I found that django migrations don't designed for live updates on large
> tables for postgres, eg. index creation doesn't use concurre
Hi,
I found that django migrations don't designed for live updates on large
tables for postgres, eg. index creation doesn't use concurrently or alter
table operation can take ACCESS EXCLUSIVE lock for long time.
Before I mostly wrote custom migrations, but after one of downtime I
Hi Brian,
On Fri, 25 Jul 2014, Brian May wrote:
> I can't help but think this might be unrealistic (?). Changes required for
> new versions of Django often break compatibility with old versions, and
> 1.4.5 is really old now. Just because many packages don't have versioned
> dependencies on Django
Hi Andrew,
thanks for your quick answer.
On Thu, 24 Jul 2014, Andrew Godwin wrote:
> There is no way around this; it's unfortunate that the packaging situation
> means that Django will get auto-upgraded as part of a distribution upgrade;
> I'm surprised that Debian hasn't had this with packages
> schema migrations managed by South but the system will have Django 1.7
> and we have no means to let the users apply those schema changes.
>
> I see two ways to go forward:
> - either we find a way to apply South migrations with Django 1.7
> - or we enhance Django migrations to
On Thu, Jul 24, 2014 at 4:44 PM, Joseph Curtin <4...@jbcurtin.io> wrote:
>
> My question now would be, can django migrations and south migrations
> co-exist and can I turn off django migrations?
>
No, migrations is a required feature of Django and cannot be turned off.
The be
h the assumption: I should be able to create
an initial migration and go from there.
One complication I see with this, is that only the django runtime knows
about south which makes it near impossible to detect this in your
packaging.
My question now would be, can django migrations and south migratio
ans to let the users apply those schema changes.
I see two ways to go forward:
- either we find a way to apply South migrations with Django 1.7
- or we enhance Django migrations to be able to tag some point
in the Django migrations as equivalent to some other point in the
South migrations, that
Lets get this into 1.1 ;)
-dave
On Sat, Jan 3, 2009 at 7:02 PM, Brantley Harris wrote:
>
> On Sat, Jan 3, 2009 at 5:25 PM, Russell Keith-Magee
> wrote:
> >
> > On Sun, Jan 4, 2009 at 4:28 AM, Brantley Harris
> wrote:
> >> Ah yes, this is definitely a problem. See, I had to be able to import
>
On Sat, Jan 3, 2009 at 5:25 PM, Russell Keith-Magee
wrote:
>
> On Sun, Jan 4, 2009 at 4:28 AM, Brantley Harris wrote:
>> Ah yes, this is definitely a problem. See, I had to be able to import
>> based on a string (database backend), and I was having problems doing
>> so without an absolute impor
On Sun, Jan 4, 2009 at 4:28 AM, Brantley Harris wrote:
>
> On Sat, Jan 3, 2009 at 4:43 AM, Russell Keith-Magee
> wrote:
>> If there is some technical reason why the django.contrib namespace is
>> required, then raise that issue on the developers list and we can see
>> what we can do to break tha
On Sat, Jan 3, 2009 at 4:43 AM, Russell Keith-Magee
wrote:
> In the aftermath of DjangoCon [1], Simon Willison, Andrew Godwin and
> myself started the django-migrations SIG [2], with the aim of getting
> a migrations framework into the Django core that draws from the best
> parts
Russ has made some good points, but I feel a need to chime in anyway!
Brantley Harris wrote:
> The idea is a database migration system that:
> * Is simple.
> * Doesn't make you use sql. This is an orm, we shouldn't have to use sql.
>
As Russ said, there's a need for SQL, and his point
On Sat, Jan 3, 2009 at 5:29 AM, Brantley Harris wrote:
>
> Having not been content with the state of Django migrations systems,
> I've created one of my own:
>
> http://www.bitbucket.org/DeadWisdom/migratory/
In the aftermath of DjangoCon [1], Simon Willison, Andrew Godwi
l on your page, how does the
> > migration process looks like with your app?
>
> > On Sat, Jan 3, 2009 at 2:29 AM, Brantley Harris
> > wrote:
>
> >> Having not been content with the state of Django migrations systems,
> >> I've created one of
2009 at 2:29 AM, Brantley Harris wrote:
>>
>> Having not been content with the state of Django migrations systems,
>> I've created one of my own:
>>
>> http://www.bitbucket.org/DeadWisdom/migratory/
>>
>> The idea is a database migration system that:
&
Could you please write some tutorial on your page, how does the
migration process looks like with your app?
On Sat, Jan 3, 2009 at 2:29 AM, Brantley Harris wrote:
>
> Having not been content with the state of Django migrations systems,
> I've created one of my own:
>
> http
Having not been content with the state of Django migrations systems,
I've created one of my own:
http://www.bitbucket.org/DeadWisdom/migratory/
The idea is a database migration system that:
* Is simple.
* Doesn't make you use sql. This is an orm, we shouldn't have to use
23 matches
Mail list logo
