part of 1.9. However, since the reason for putting that on the
> deprecation timeline was that syncdb used to use the old DDL code, this
> argument does not hold anymore. syncdb uses the same DDL code as migrations.
>
> /Markus
>
>
> On Wednesday, June 3, 2015 at 1:16:37 PM UTC+2
n the
deprecation timeline was that syncdb used to use the old DDL code, this
argument does not hold anymore. syncdb uses the same DDL code as migrations.
/Markus
On Wednesday, June 3, 2015 at 1:16:37 PM UTC+2, Andriy Sokolovskiy
(coldmind) wrote:
>
> After discussion with Markus Holtermann, we d
After discussion with Markus Holtermann, we decided that we need to
deprecate internal syncdb in 1.9
(https://github.com/django/django/blob/7c637a3aaec311269bf863c220bf894eebbe7c7c/django/core/management/commands/migrate.py#L136)
The fact that apps without migrations are not supported, which is
Hello everyone,
As we all know that syncdb is the command used in django to create
tables and we also know that it does mot update tables once it is
created. But why does it happen?
Has anyone thought about it? For updating it we need to use south and
django migrations.
Actually I want to do
Hi Harjot,
syncdb has in fact been deprecated in 1.7 and replaced with migrate [1], so
what you propose has already been accomplished!
Andrew
[1]: https://docs.djangoproject.com/en/dev/releases/1.7/#schema-migrations
On Wed, Feb 5, 2014 at 6:35 PM, Harjot Mann wrote:
> Hello everyone,
&
x27;t plan to add in an equivalent to "syncdb --all" - the squashing
should be enough to make things nice and fast for testing, and will have
the added benefit where your test database matches your production one more
closely. Squash (what was previously called rebase) is designed to let you
ary which has a long migration history
included, when we start a new site using it we generally use `syncdb --all`
so as not to worry about the history. Will this command still be supported
by the new `migrate` command?
I can see the argument for making sure the migrations work, and they may be
thout them.
However, I understand people don't like doing this. Problem is, the
alternative is to reserve the old syncdb method for running tests, and
then to introduce a new setting (which in South
is SOUTH_TESTS_MIGRATE) that lets users turn it on and off, which
seems like a bad road to g
o say what
to do here.
I personally have the opinion that stuff you add in data migrations
_should_ be part of the tests - after all, it's usually crucial data that
the site won't work without, and you're never going to test an installation
without them.
However, I understand people don
On 30/05/13 20:55, Andrew Godwin wrote:
> The way South works, and the way this will work (for new installs as
> well as tests) is that if migrations are present for an app, it will
> always create new databases by running through them from the very first
> migration to the latest one.
One proble
On Fri, May 31, 2013 at 2:03 AM, Andrew Godwin wrote:
> Hi everyone,
>
> I'm starting to plan out the commands for the new migrations stuff in
> Django, and I've hit something of an impasse trying to decide which option
> to go for.
>
> Short background: South m
ing
> for test database setup, except that you run all migrations against
> empty database? The first migration would be the initial "syncdb", and
> then you run rest of the migrations in chain finally arriving to the
> wanted database state. Or would it be "sync"
+1 on option 3.
In hindsight syncdb isn't a good name. It won't be missed. Please deprecate it.
--
Aymeric.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails fr
On 30 touko, 21:03, Andrew Godwin wrote:
> I prefer option 3, but getting rid of syncdb might be controversial, so I
> want to ask for people's opinions. syncdb would continue to exist for at
> least 3 versions if not forever; it would just be an alias to run "migrat
Hi all,
On Thursday 30 May 2013, Andrew Godwin wrote:
>
> The proposals are:
>
> 1. Change syncdb so that it both does the old behaviour (adds models for
> unmigrated apps), and additionally runs any outstanding migrations. There
> would be a separate "migrate&qu
On 30.05.2013, at 20:03, Andrew Godwin wrote:
> Hi everyone,
>
> I'm starting to plan out the commands for the new migrations stuff in Django,
> and I've hit something of an impasse trying to decide which option to go for.
>
> Short background: South modified sync
On 05/30/2013 12:03 PM, Andrew Godwin wrote:
> The proposals are:
>
> 1. Change syncdb so that it both does the old behaviour (adds models
> for unmigrated apps), and additionally runs any outstanding migrations.
> There would be a separate "migrate" command for more c
r the new migrations stuff in
> Django, and I've hit something of an impasse trying to decide which option
> to go for.
>
> Short background: South modified syncdb to just sync non-migrated apps,
> and you had to go and run migrate separately to get migrations working.
>
>
On May 30, 2013, at 2:03 PM, Andrew Godwin wrote:
> Hi everyone,
>
> I'm starting to plan out the commands for the new migrations stuff in Django,
> and I've hit something of an impasse trying to decide which option to go for.
>
> Short background: South modi
Hi everyone,
I'm starting to plan out the commands for the new migrations stuff in
Django, and I've hit something of an impasse trying to decide which option
to go for.
Short background: South modified syncdb to just sync non-migrated apps, and
you had to go and run migrate separat
ks good to me.
I am thinking of adding a "for_action" kwarg for post_syncdb.
Currently there is no way to distinguish between flush and syncdb.
This makes it impossible to use the signal for schema changes. I guess
the kwarg could be useful for migrations, too.
Does this sound reasonab
On May 21, 2013, at 12:11 PM, peter wrote:
> +1 on pre_syncdb
>
> On Tuesday, May 21, 2013 8:29:49 AM UTC-7, Shai Berger wrote:
> On Tuesday 21 May 2013, Donald Stufft wrote:
> > I run migrations in test. How else will you know your db reflects reality
> > :/
> >
>
> When you have a few hu
the
project in this incomplete state, you'll get unpredictable behaviour from
any join on this foreign key. Then, when you *do* run the syncdb on the
second application, you need to be able to identify which foreign key
columns have been correctly constrained.
While it may be *possible* to
On Thursday 23 May 2013, Łukasz Langa wrote:
> On 23 maj 2013, at 00:52, Shai Berger wrote:
> > If I'm not mistaken, there are some problems with the latest released
> > version (0.7.6)
>
> FWIW, the latest released version is 0.8 as of earlier today:
>
Can't take your eyes off Andrew for a minu
On 23 maj 2013, at 00:52, Shai Berger wrote:
> If I'm not mistaken, there are some problems with the latest released version
> (0.7.6)
FWIW, the latest released version is 0.8 as of earlier today:
https://pypi.python.org/pypi/South
--
Best regards,
Łukasz Langa
WWW: http://lukasz.langa.pl/
On Thursday 23 May 2013, Michał Nowotka wrote:
> I don't and I won't (south is not working with Oracle).
This discussion is getting to a place where it belongs either on django-users
or south-users; I should point out, though, that South does work with Oracle.
If I'm not mistaken, there are some
I don't and I won't (south is not working with Oracle).
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To p
If you have south installed, I believe you can use migrate which takes an
app argument.
python manage.py migrate myapp
-A
On Wed, May 22, 2013 at 12:50 PM, Michał Nowotka wrote:
> Hello,
>
> Is the any particular reason why syncdb doesn't have argument with list of
> a
Hello,
Is the any particular reason why syncdb doesn't have argument with list of
applications to be synced?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it
+1 on pre_syncdb
On Tuesday, May 21, 2013 8:29:49 AM UTC-7, Shai Berger wrote:
>
> On Tuesday 21 May 2013, Donald Stufft wrote:
> > I run migrations in test. How else will you know your db reflects
> reality
> > :/
> >
>
> When you have a few hundred migrations, that's something you're willin
On Tuesday 21 May 2013, Donald Stufft wrote:
> I run migrations in test. How else will you know your db reflects reality
> :/
>
When you have a few hundred migrations, that's something you're willing to do
in your CI server, but not on your development machine.
Shai.
--
You received this mess
t; There's already a patch on the ticket tracker for a pre_syncdb signal, and
>>> yesterday I started updating it and modifying it a bit as I needed this
>>> signal.
>>>
>>> https://github.com/dstufft/django/compare/pre-syncdb-signal
>>>
>>
; On Sat, May 18, 2013 at 7:15 PM, Donald Stufft
> > wrote:
>
>> There's already a patch on the ticket tracker for a pre_syncdb signal,
>> and yesterday I started updating it and modifying it a bit as I needed this
>> signal.
>>
>> https://github.c
needed this
> signal.
>
> https://github.com/dstufft/django/compare/pre-syncdb-signal
>
> On May 18, 2013, at 1:06 PM, Karol Sikora wrote:
>
> I can try to implement approach with pre_syncdb signal tomorrow. I think
> that is quite enough solution before deeper diggling into new mi
There's already a patch on the ticket tracker for a pre_syncdb signal, and
yesterday I started updating it and modifying it a bit as I needed this signal.
https://github.com/dstufft/django/compare/pre-syncdb-signal
On May 18, 2013, at 1:06 PM, Karol Sikora wrote:
> I can try to i
denote, there was a discussion about this on this mailing list a
> few
> > months ago:
> >
> > https://groups.google.com/forum/#!searchin/django-developers/16550/dj...
>
> I think a pre_sync signal is best approach. The signal should be
> called either just after connecting to
either just after connecting to the (test) DB in syncdb
command, or maybe just after existing tables have been introspected so
that you know what tables are already there. Latter might be better as
syncdb can be ran multiple times, and you only need to CREATE
EXTENSION on initial sync. OTOH if you
As a sidenote, there was a discussion about this on this mailing list a few
months ago:
https://groups.google.com/forum/#!searchin/django-developers/16550/django-developers/xN0aMzrmA1Y/KsrsEf7XOA8J
--
You received this message because you are subscribed to the Google Groups
"Django developers"
a way to
> run some custom SQL in tests after the DB gets created by the test
> harness but before syncdb runs.
>
> The current patch and suggested solution on the ticket won't work (see
> the thread), but I think it's a legit need and I'd like to come up
> with a
ay to
> run some custom SQL in tests after the DB gets created by the test
> harness but before syncdb runs.
>
> The current patch and suggested solution on the ticket won't work (see
> the thread), but I think it's a legit need and I'd like to come up
> with a
efore syncdb runs.
The current patch and suggested solution on the ticket won't work (see
the thread), but I think it's a legit need and I'd like to come up
with a good solution and possibly reopen the ticket.
Jacob
--
You received this message because you are subscribed to the Go
via a single
> command migrate_all_databases (which calls south's migrate and django's
> syncdb on every database). There is however a shared database, where all
> tenants have access to. I'd like this shared database to have different
> models than the models on the te
d django's
syncdb on every database). There is however a shared database, where all
tenants have access to. I'd like this shared database to have different
models than the models on the tenants, which would involve having two
different settings for INSTALLED_APPS. I've tried simp
On Tue, Dec 1, 2009 at 2:25 AM, Thibaud Morel l'Horset
wrote:
> Hi,
>
> Syncdb will currently automatically load inital data fixtures if the
> files are there, even they are overwriting existing data in the db.
> This seems
> contrary to the principle stated in the syncd
Hi,
Syncdb will currently automatically load inital data fixtures if the
files are there, even they are overwriting existing data in the db.
This seems
contrary to the principle stated in the syncdb documentation that it
will never alter existing data (see
http://docs.djangoproject.com/en
On Wed, 2009-05-13 at 17:20 -0400, J. Cliff Dyer wrote:
> On Wed, 2009-05-13 at 15:31 -0400, J. Cliff Dyer wrote:
> > On Wed, 2009-05-13 at 14:40 -0400, J. Cliff Dyer wrote:
>
> > > [...] but it occurs to me that if through=MyModel is set on the
> > > ManyToMany, the sequence on MyModel will alre
On Wed, 2009-05-13 at 15:31 -0400, J. Cliff Dyer wrote:
> On Wed, 2009-05-13 at 14:40 -0400, J. Cliff Dyer wrote:
> > [...] but it occurs to me that if through=MyModel is set on the
> > ManyToMany, the sequence on MyModel will already be handled by the loop
> > at line 112. I think I can code up
On Wed, 2009-05-13 at 14:40 -0400, J. Cliff Dyer wrote:
> On Wed, 2009-05-13 at 12:49 -0400, J. Cliff Dyer wrote:
> > Setup:
> >
> > Ubuntu 9.04
> > Python 2.6.2
> > Django 1.0.2
> > Postgres 8.3.7
> > postgresql-psycopg2
> >
> > I'
On Wed, 2009-05-13 at 12:49 -0400, J. Cliff Dyer wrote:
> Setup:
>
> Ubuntu 9.04
> Python 2.6.2
> Django 1.0.2
> Postgres 8.3.7
> postgresql-psycopg2
>
> I'm having issues using ./manage.py syncdb and ./manage.py flush with a
> project of mine. I
Setup:
Ubuntu 9.04
Python 2.6.2
Django 1.0.2
Postgres 8.3.7
postgresql-psycopg2
I'm having issues using ./manage.py syncdb and ./manage.py flush with a
project of mine. I've got an app, venues, which defines a
ManyToManyField.
After syncdb loads the fixtures, (and only if it tri
On Wed, 2009-03-04 at 08:20 -0800, boyombo wrote:
> I encountered the issue written about in Ticket #4140 while deploying
> an application on oracle. I later found that the problem stemmed from
> me using field name 'date', which is a keyword, in some of my models.
> I did my development on MySQL.
I encountered the issue written about in Ticket #4140 while deploying
an application on oracle. I later found that the problem stemmed from
me using field name 'date', which is a keyword, in some of my models.
I did my development on MySQL.
I think this problem should be documented properly, perha
Sorry, disregard.
On Jun 4, 8:40 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Wed, Jun 4, 2008 at 8:26 PM, greg.newman <[EMAIL PROTECTED]> wrote:
>
> > I'm trying to syncdb in a project and am getting the following error
> > running pyt
On Wed, Jun 4, 2008 at 8:26 PM, greg.newman <[EMAIL PROTECTED]> wrote:
>
> I'm trying to syncdb in a project and am getting the following error
> running python 2.5.1 with django 0.96.
> Anyone have a clue why? Need more info, let me know.
Django-developers is for discus
I'm trying to syncdb in a project and am getting the following error
running python 2.5.1 with django 0.96.
Anyone have a clue why? Need more info, let me know.
greg-3:examples greg$ python manage.py syncdb
Traceback (most recent call last):
File "manage.py", line 16, in
t for some existing
>> sites
>> that I'm upgrading, it's very useful to be able to run syncdb without
>> loading any fixtures. Thus http://code.djangoproject.com/ticket/6511
I'm -0 to the original idea. I would be +1 to the idea if a different
management co
On Jan 30, 2008 8:17 AM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> I ran into a situation today where for every future site I set up,
> I'll want to load an initial_data fixture, but for some existing sites
> that I'm upgrading, it's very useful to be abl
I ran into a situation today where for every future site I set up,
I'll want to load an initial_data fixture, but for some existing sites
that I'm upgrading, it's very useful to be able to run syncdb without
loading any fixtures. Thus http://code.djangoproject.com/ticket/6511
I&
On Jan 26, 2008 3:19 AM, Martin Ostrovsky <[EMAIL PROTECTED]> wrote:
>
> I posted in this in the Users group, but thought somebody here might
> want to see this as well ...
Please don't do this. Django-developers isn't the 'hard questions that
couldn't be answered on django-users' mailing list -
Forgot to add, I'm using Django from trunk, latest revision.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubs
I posted in this in the Users group, but thought somebody here might
want to see this as well ...
I'm trying to run syncdb on a clean database (no other tables etc.)
in
postgres. It produces the standard Postgres error:
psycopg2.ProgrammingError: current transaction is aborted, commands
ig
On 9/6/07, Paul Davis <[EMAIL PROTECTED]> wrote:
> I think the biggest issue is the fact that:
> $ python manage.py sqlcustom appname
> gives sql thats in a transaction. It was confusing to have the two
> different behaviors.
Ah - interesting. That should probably be raised as a bug (with a
sugg
On 9/5/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> On 9/6/07, Paul Davis <[EMAIL PROTECTED]> wrote:
> >
> > I'm having a bit of a problem using the appname/sql/model.sql custom
> > sql files.
> ...
> > But running:
> > $ python manage.py sqlcustom root | psql eureka
> >
> > Completes wi
On 9/6/07, Paul Davis <[EMAIL PROTECTED]> wrote:
>
> I'm having a bit of a problem using the appname/sql/model.sql custom
> sql files.
...
> But running:
> $ python manage.py sqlcustom root | psql eureka
>
> Completes wihtout errors. So, I'm fairly certain that the custom sql
> is not being run in
I'm having a bit of a problem using the appname/sql/model.sql custom
sql files.
Running:
$ python manage.py syncdb root
Gives:
Installing custom SQL for root.Status model
Installing custom SQL for root.Target model
Installing custom SQL for root.Reference model
Installing custom SQ
.html
I've hacked a standalone script to delete old entries in the tables
"django_content_type" and "django_content_type":
http://paste.pocoo.org/show/1482/
This it not enough. Other tables must be still updated:
"auth_user_user_permissions", "auth_group_permissions&q
On 4/4/07, SmileyChris <[EMAIL PROTECTED]> wrote:
> I'd like to challenge the closing of
> http://code.djangoproject.com/ticket/2229#comment:4
>
> I do see Russell's point about syncdb not having schema-evolution
> behaviour for data fields, but it DOES have schema
On Wed, 2007-04-04 at 05:28 +, SmileyChris wrote:
> I'd like to challenge the closing of
> http://code.djangoproject.com/ticket/2229#comment:4
>
> I do see Russell's point about syncdb not having schema-evolution
> behaviour for data fields, but it DOES have schem
I'd like to challenge the closing of
http://code.djangoproject.com/ticket/2229#comment:4
I do see Russell's point about syncdb not having schema-evolution
behaviour for data fields, but it DOES have schema-evolution for
missing tables - you don't have to drop the whole app.
Let me preface this by saying that I do have a small test app running
hitting two databases and pulling back information from both of
these
I decided today to try and use the Admin capability in django... and
then realized that django will generate its own tables when running
syncdb for this
Russell Keith-Magee wrote:
> You are correct (and it's not just with MySQL). This is a bug born of
> the way that syncdb installs applications. For some reason, it doesn't
> defer to install - it duplicates the install logic, but doesn't include
> indexes.
>
&g
On 8/24/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
It looks like syncdb has a bug in that it doesn't create the indexes --at least on MySQL.
You are correct (and it's not just with MySQL). This is a bug born of the way that syncdb installs applications. For some reason, it
The tutorial says and mentions that it creates indexes explicitly.
The syncdb command runs the sql from 'sqlall' on your database for all
apps in INSTALLED_APPS that don't already exist in your database. This
creates all the tables, initial data and indexes for any apps you hav
Yes, that worked.
But the documentation always seems to recommend running ./manage.py
syncdb after you set up your models. It should also create any indexes
you have defined.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
odels.TextField(blank=True)
>
> class Text(models.Model):
> page = models.ForeignKey(Page, db_index=True,
> edit_inline=models.STACKED)
> content = models.TextField(core=True)
>
> When I run "./manage.py syncdb" it creates the tables and everything
> wo
ACKED)
content = models.TextField(core=True)
When I run "./manage.py syncdb" it creates the tables and everything
works ok, but if I look in MySQL at the table description, the index
isn't listed:
mysql> desc page_text;
+--+--+--+-+-+--
Michael Radziej wrote:
> DavidA wrote:
> > I've been having a problem rebuilding my database from scratch via
> > syncdb. I've tracked it down to duplicate constraint name. Here is the
> > output from manage.py sql for my app:
> > ...
> > This used to w
DavidA wrote:
> I've been having a problem rebuilding my database from scratch via
> syncdb. I've tracked it down to duplicate constraint name. Here is the
> output from manage.py sql for my app:
> ...
> This used to work, I'm pretty sure, but I haven't rebuil
I mistakenly posted this in django-users so reposting here...
--
I've been having a problem rebuilding my database from scratch via
syncdb. I've tracked it down to duplicate constraint name. Here is the
output from manage.py sql for my app:
ALTER TABLE `data_rawinst` ADD
On 4/8/06, Max Battcher <[EMAIL PROTECTED]> wrote:
> I've been seeing this at the end of every manage.py command. It does
> appear to be non-fatal, but it is something that needs to be debugged.
> Sorry I haven't taken the time yet to file a formal report. This was on
> my Windows development ma
"bradford" <[EMAIL PROTECTED]> writes:
> Go an error running the following:
>
> $ python manage.py syncdb
[snip]
> Exception exceptions.AttributeError: "'NoneType' object has no
> attribute 'print_exc'" in
> ignored
This is rela
bradford wrote:
> Exception exceptions.AttributeError: "'NoneType' object has no
> attribute 'print_exc'" in ignored
I've been seeing this at the end of every manage.py command. It does
appear to be non-fatal, but it is something that needs to be debugged.
Sorry I haven't taken the time yet t
Go an error running the following:
$ python manage.py syncdb
Creating table auth_message
Creating table auth_group
Creating table auth_user
Creating table auth_permission
Creating many-to-many tables for Group model
Creating many-to-many tables for User model
Creating table django_content_type
magical-removal branch where this is not
>> yet implemented.
>
> sqlinitialdata _was_ implemented, but it's been removed in favour of
> the new syncdb command. syncdb has been under development this week -
> it looks like Jacob put initdata stuff back in with r2482.
>
>
initialdata _was_ implemented, but it's been removed in favour of
the new syncdb command. syncdb has been under development this week -
it looks like Jacob put initdata stuff back in with r2482.
Thanks for the report, though. Does Jacob's patch restore all the
behavio
s .sql files from the app/sql/ folder and
executes them, which is just what i need. It also gets called from
syncdb after that has finished its own business. Should sqlinitialdata
take care of anything else?
If so could someone explain what?
I'ld be happy to implement this.
[1] http://code
On 3/1/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> I just wanted to say that 'syncdb' is great! You guys rock.
>
> And a big thanks to Georg too for the transaction stuff - I've been
> looking on in admiration over the past few days.
Plenty of awesome improvem
Adrian (and anyone else responsible - Jacob?),
I just wanted to say that 'syncdb' is great! You guys rock.
And a big thanks to Georg too for the transaction stuff - I've been
looking on in admiration over the past few days.
Luke
--
"Smoking cures weight problems...ev
88 matches
Mail list logo
