It depends about your workflow - if migrations were applied only on your
machine, revert them and modify.
South migrations (and Django migrations, which were based on South) may be
problematic in speific cases, i.e. during merging or when executed
unintentionally from uncleaned *.pyc files, but
On 04/25/2015 05:18 PM, Carl Meyer wrote:
> You can use the "squash" feature [1] to squash a set of historical
> migrations down to a single migration.
Forgot this link:
https://docs.djangoproject.com/en/1.8/topics/migrations/#squashing-migrations
Carl
--
You received this message because you a
On 04/25/2015 11:28 AM, Timothy W. Cook wrote:
> if you don't store migrations, then you have to generate them on each
> production update, right? if so, wouldn't they count as untested
> code? how about manually tweaked, or data migrations?
>
>
> That will certainly be true once y
On 04/25/2015 11:15 AM, Javier Guerra Giraldez wrote:
> On Sat, Apr 25, 2015 at 12:08 PM, Timothy W. Cook
> wrote:
>>
>> On Sat, Apr 25, 2015 at 9:48 AM, Jorge Andrés Vergara Ebratt
>> wrote:
>>>
>>> Are you using version control like GIT? I save the migration
>>> folder with the __init__.py in
On 04/25/2015 06:48 AM, Jorge Andrés Vergara Ebratt wrote:
> Are you using version control like GIT? I save the migration folder with
> the __init__.py in GIT, nothing else, because al the migrations will be
> diferent in the diferent servers.
This is not a good idea. Migrations should be committe
Hi Timothy,
Assuming as an example that 0002_<>.py is the migration that you have
already applied to production server, this is the scheme I follow:
- Make sure you have your local db up to date i.e. all the model changes
have been applied to database.
- Fake a reversal to the last migra
On Sat, Apr 25, 2015 at 12:28 PM, Timothy W. Cook wrote:
> On Sat, Apr 25, 2015 at 2:15 PM, Javier Guerra Giraldez
> wrote:
>> if you don't store migrations, then you have to generate them on each
>> production update, right? if so, wouldn't they count as untested
>> code? how about manually tw
On Sat, Apr 25, 2015 at 2:15 PM, Javier Guerra Giraldez
wrote:
>
>
> with South i used to save them to the repo too and push whole to
> production. haven't tried Django migrations yet; is there any
> difference that make this more appropriate?
>
>
Hmmm, good question. That was kind of my quest
On Sat, Apr 25, 2015 at 12:08 PM, Timothy W. Cook wrote:
>
> On Sat, Apr 25, 2015 at 9:48 AM, Jorge Andrés Vergara Ebratt
> wrote:
>>
>> Are you using version control like GIT? I save the migration folder with the
>> __init__.py in GIT, nothing else, because al the migrations will be diferent
On Sat, Apr 25, 2015 at 9:48 AM, Jorge Andrés Vergara Ebratt <
javebr...@gmail.com> wrote:
> Are you using version control like GIT? I save the migration folder with
> the __init__.py in GIT, nothing else, because al the migrations will be
> diferent in the diferent servers.
>
>
This is probably
On 25/04/2015 10:26 PM, Timothy W. Cook wrote:
Django 1.8 Â Python 3.4 PostgreSQL 9.3
During development I am creating several migrations. It seems
unnecessary to keep these since they only exist on my dev machine. Â
Any data that I have created can be thrown away too.
Is it safe to delete thes
Are you using version control like GIT? I save the migration folder with
the __init__.py in GIT, nothing else, because al the migrations will be
diferent in the diferent servers.
On Sat, Apr 25, 2015, 7:45 AM Filipe Ximenes
wrote:
> You should keep all project migrations, they will be used to up
You should keep all project migrations, they will be used to update the
database everytime a change is made. This applies to your local project,
the staging server (if you have one) and your production server.
If you are worried about having to many migrations, you can delete the ones
that were not
13 matches
Mail list logo
