Hi,
I have a project, which works on server for some time, but:
I need to develop it, so I want to run in docker locally. That is easy. But
i cannot just copy DB from production, because it contains sensitive
informations. OK, I just deleted DB and want to start app. Migrations
should work ever
Dear Django community,
in a project, I’m struggling to fix a problem with my database schema and
data migrations.
Here’s what I want to do:
My application used to have a “Person” model. As time went by, it turned
out that we would also need an model for “Organization”. Both should
inherit the
I have 4 MySQL databases and use routers to manage them.The tables are created
and the migration is successful however django server shows one migration to be
applied. If the command is to ". python3 manage.py migrate" it does apply the
migration but to the auth table which is the default table
Hi Harish,
Did you commit your changes to git/svn repo after changing the models?
Did they fetch the latest changes from the repo?
Is your db file also in repo?
If yes, there would a table inside the database db.sqlite3, which stores
the information about which migrations were executed.
You have
In django models i added a new field
in my system its working fine.
but in other systems its showing no migrations to apply
how to solve it without effecting data?
i tried deleting contents of migrations folder except __init__.py
enter code here
but still same error
what is real method to
I tried it and getting this error
INFO 2018-05-02 15:15:22,713 CATMAID was unable to load the h5py library,
which is an optional dependency. HDF5 tiles are therefore disabled. To
enable, install h5py.
WARNING 2018-05-02 15:15:22,982 NeuroML module could not be loaded.
Traceback (most recent call l
If you have the original models.py files just run "python manage.py
makemigrations" and then "python manage.py migrate".
On Wednesday, 02 May, 2018 05:11 PM, Ank wrote:
Dear All,
I would like to do some migrations that are compatible with older
django version using southdb to the newer versi
Dear All,
I would like to do some migrations that are compatible with older django
version using southdb to the newer version. How can these files be
updated.iḿ attaching one of the file that is needed to be migrated.
Any help will be appreciated
Best
Ank
--
You received this message b
Hi there
To go to a specific migration just run
$ python manage.py migrate
About your data I think is better you make backup.
Em 11 de set de 2017 20:11, "Luis Zárate" escreveu:
Hello people,
I really would like you to help me with some thing I need to solve.
I have an app that do autom
Hello people,
I really would like you to help me with some thing I need to solve.
I have an app that do automated deployment of django apps, that also can
update existing deployments. So I need to revert my database to last state
if something went wrong.
So, my question is, how can I revert all
On Thursday 02 March 2017 10:45:50 Michal Petrucha wrote:
> On Wed, Mar 01, 2017 at 07:45:24PM -0500, Ed Sutherland wrote:
> > The problem surrounded a textfield that had no default. I added the
> > default string and migrate complained it was an int. I changed the
> > string and migrate still comp
On Wed, Mar 01, 2017 at 07:45:24PM -0500, Ed Sutherland wrote:
> The problem surrounded a textfield that had no default. I added the
> default string and migrate complained it was an int. I changed the
> string and migrate still complains of the int default that no longer
> exists.
Hi Ed,
When tr
The problem surrounded a textfield that had no default. I added the
default string and migrate complained it was an int. I changed the string and
migrate still complains of the int default that no longer exists. On Wed,
01 Mar 2017 15:50:07 -0500 Melvyn Sopac
On Wednesday 01 March 2017 13:27:37 Ed Sutherland wrote:
> I am a relatively new Django coder. I'm building a small custom
CMS.
> Whenever I get deep into development, I run into a migration
problem:
> an old error keeps halting newer migrations. I long ago fixed the
> original error, but the mig
I am a relatively new Django coder. I'm building a small custom CMS. Whenever I
get deep into development, I run into a migration problem: an old error keeps
halting newer migrations. I long ago fixed the original error, but the
migration continues to stop due to a now non-existent error. I know
Ah ok thanks, well generally it's not a blocker, except that we first have
to upgrade to 1.10.
We have done a lot of migrations in the last few months and given the size
of the project it always takes a long time from one version to the other,
so just not sure when I'll be able to test these ch
Per our support versions policy, Django 1.9.x is only receiving fixes for
security and data loss issues. Migrations optimizations are unlikely to
qualify for a backport to Django 1.10.x either. Hopefully that doesn't
demotivate you from contributing an improvement.
https://docs.djangoproject.co
Thanks Marcus and others, this issue is in general getting worse and worse.
We did some more investigation and we should probably just help out the
work you are doing.
Do you think it would be possible to apply these changes also on Django
1.9.9 or it has to be from master/1.10 only?
I also tr
I think that error suggests that you disabled migrations for an app
(something_else) that's a dependency of another app that doesn't have
migrations disabled (something). That isn't permitted. I guess there's no
good solution for your requirements as of now.
On Monday, August 8, 2016 at 6:02:48
Since we also use --keepdb I thought we could simply avoid running all the
migrations, and maybe dynamically even skip all the apps that were not
changed at all.
So I just tried something silly like this:
NO_MIGRATIONS = os.environ.get('NO_MIGRATIONS', 'false').lower() in
('true', '1')
if NO
As long as your tests don't rely on any data migrations, you can set
MIGRATIONS_MODULES['app'] = None for all apps in a test settings file as
described in
https://docs.djangoproject.com/en/stable/ref/settings/#std:setting-MIGRATION_MODULES
to disable migrations while testing. There's a ticket
Ok great thanks for the answer Markus.
And yes I can try to help, it's quite a big issue for us..
Anything else we can do to improve the situation in the meanwhile?
In general I was wondering why do we need to handle all the "baggage" of
supporting backward migrations and doing things 100% prope
Thanks Andrea,
this is a known issue. Let me give you a bit of a history on this:
In 1.7 Django didn't do any caching. That was awfully slow for huge
projects like yours.
In 1.8 Django introduced heavy caching. Things improved speed wise but
failed horrifically when you were altering relations
query.Basically I want
>> to inspect how the sql query generated as in the output of "./manage.py
>> sqlmigrate" is being generated.I've generally used "pdb" along wth
>> unittest.TestCase,but for migrations I'm pretty much stuck.Does anyone
&g
;m pretty much stuck.Does anyone
> probably have a sample test they wrote to test the django migrations.
> Thanks in advance.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this
"pdb" along wth
unittest.TestCase,but for migrations I'm pretty much stuck.Does anyone
probably have a sample test they wrote to test the django migrations.
Thanks in advance.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
Hi Carl,
Thanks for pointing this out - it's right there! I don't know how I missed
it...
Thanks again,
R.
On Mon, Aug 10, 2015 at 11:12 AM, Carl Meyer wrote:
> Hi Richard,
>
> On 08/01/2015 06:27 PM, Richard Brockie wrote:
> > Can someone please explain the implications of this note about squ
Hi Richard,
On 08/01/2015 06:27 PM, Richard Brockie wrote:
> Can someone please explain the implications of this note about squashing
> migrations in the documentation?
>
> From: https://docs.djangoproject.com/en/1.7/topics/migrations/
>
> "Once you’ve squashed a migration, you should not th
Hi everyone,
Can someone please explain the implications of this note about squashing
migrations in the documentation?
From: https://docs.djangoproject.com/en/1.7/topics/migrations/
"Once you’ve squashed a migration, you should not then re-squash that
> squashed migration until you have fully
I'm not a newbie. Just avoid Django (South) migrations and syncdb.
My advice - generate complete SQL for your project (based on migrations or
sql and sqlindexes commands), move changes to reliable tool (i.e.
Liquibase) as an initial migration, tune changesets if needed, and forget
about builtin
I'm a newbie here so be careful.
I believe you can use
manage.py migrate --fake
That works for me.
Johnf
On 04/23/2015 11:37 AM, Rick Weinberger wrote:
I posted the same question on stack overflow, here:
http://stackoverflow.com/questions/29830928/django-db-utils-programmingerror-relation-alrea
I posted the same question on stack overflow, here:
http://stackoverflow.com/questions/29830928/django-db-utils-programmingerror-relation-already-exists
I basically can't figure out how to get my app to migrate, and I can't use
syncdb, because I inherit from contrib.auth. I also can't find any
On Wed, Sep 10, 2014 at 02:06:09PM -0500, Andrew Pinkham wrote:
> On Sep 10, 2014, at 12:25 PM, John Schmitt wrote:
> > Which file? What do I look for? What do I 'verify' and to what should it
> > be compared?
>
> When you run `makemigrations app_name`, the output will inform you of the
> cre
On Sep 10, 2014, at 12:25 PM, John Schmitt wrote:
> Which file? What do I look for? What do I 'verify' and to what should it be
> compared?
When you run `makemigrations app_name`, the output will inform you of the
creation of at least one migration file, typically in
project_name/app_name/mi
On Wed, Sep 10, 2014 at 12:08:35PM -0500, Andrew Pinkham wrote:
> Hi Jesse,
...
> Quick heads up: `syncdb` is deprecated in Django 1.7. If you're using Django
> 1.7, you should first call `makemigrations`, verify the contents of the file,
> and then call `migrate` to build/alter the database. How
Hi Jesse,
Yes, in certain cases, native Django migrations may run very slowly.
https://code.djangoproject.com/ticket/22608
My understanding is that this should not be a problem unless you have a huge
number of apps and models (note how the second benchmark from Paul in the
ticket has 200
Hi all,
First post here. I'm currently trying to transition to django migrations
which seems pretty bad ass. We currently do not use south, and keep track
of migrations manually (yuk). However, initializing a new database is
pretty straight forward; syncdb. It's quick, and efficien
Hi all,
I'm moving over to the new migrations, and I've noticed whenever I
create a migration involving a custom model field, it imports that field
at the top of the migration. The south docs were always quite firm about
not doing this sort of thing, in case the code changed in the future. Is
this
Thanks, that's what I did. In my humble opinion, the ValueError should be
removed and the timezone serialized in the form UTC offset (eg: -0400).
On Tuesday, August 12, 2014 9:43:11 PM UTC-4, Collin Anderson wrote:
>
> Wow. That almost sounds like a bug, though you can however use a callable.
>
Wow. That almost sounds like a bug, though you can however use a callable.
As ridiculous as it looks, it should work :).
INF_TIME = datetime.max.replace(tzinfo=timezone.utc)
def get_inf_time():
return INF_TIME
death = models.DateTimeField(default=get_inf_time)
What you are doing seems pret
Hello all,
I'm new to this list so please let me know I'm overlooking any sort of e
tiquette.
I'm having problem trying to use a default value for a DateTimeField. When
I specify a default value WITH a timezone I receive the following error
during './manage.py makemigrations'
ValueError: Cannot
41 matches
Mail list logo
