Re: Fate of sql* management commands

Hi Marcin, Thanks for taking the time to clarify constructively your use case. On 23 Jun 2016, at 13:10, Marcin Nowak wrote: > If it will not use migration files when they already exists, it sounds ok. I believe that this point was a big misunderstanding in the discussion. As far as I underst

Re: Fate of sql* management commands

On Thursday, June 23, 2016 at 12:12:51 AM UTC+2, Shai Berger wrote: > > > Thanks for this thoughtful clarification. I think I understand your > position > much better now. If Thanks for reading, Shai. I know my English is far from perfect, so I appreciate your involvement. I understand corr

Re: Fate of sql* management commands

Hi again Marcin, Thanks for this thoughtful clarification. I think I understand your position much better now. If I understand correctly, there are two issues you find with migrations: - They are designed to deal with schema changes, while you'd rather have a tool for one-time schema generati

Re: Fate of sql* management commands

2016-06-22 14:13 GMT+02:00 Marcin Nowak : > > The reason of removing two differenct ways of managing db schema is clear > for me. I just do not understand removing the tool without providing decent > replacement for it. For example, CBV generics were replacement for FBV > generics. There was an in

Re: Fate of sql* management commands

I can give you many reasons and many details, but I know you will not agree with my conclusions. I remember what you (or someone from the team) said about my ideas. I've shared them already and someone told me why you've decided to do it that way, and why you wouldn't change it. I'm respecting

Re: Fate of sql* management commands

I'll be happy to look at whatever you come up with or review whatever changes you think need to be made in Django to solve the ticket, however, I fail to understand how Andrew's proposal isn't suitable. Maybe you could give more specific details than "migrations may be corrupted" and "they are

Re: Fate of sql* management commands

> > > So add another step in the end to remove the temporary migrations folder > created just in order to enable sqlmigrate. If you're a real purist, add > yet > another one to make sure you don't have a django_migrations table left > over. > > Sorry, Shai, I doubt you understand the problem.

Re: Fate of sql* management commands

On Wednesday 22 June 2016 00:48:58 Marcin Nowak wrote: > > You can write the "sqlall" you want as a shell script -- remove any > > existing > > migrations, use "makemigrations" to create an initial migratgion, > > Not exactly. I'm not using migrations [.. cut ..] > So add another step in the en

Re: Fate of sql* management commands

> > > You can write the "sqlall" you want as a shell script -- remove any > existing > migrations, use "makemigrations" to create an initial migratgion, Not exactly. I'm not using migrations [.. cut ..] I repeat Aymeric's advice that spreading your frustrations over this > mailing > l

Re: Fate of sql* management commands

Marcin, You can write the "sqlall" you want as a shell script -- remove any existing migrations, use "makemigrations" to create an initial migratgion, which will exactly reflect your models, and run sqlmigrate on that. You want to do that against a clean database, to make sure no migration has

Re: Fate of sql* management commands

On Tuesday, June 21, 2016 at 10:55:13 PM UTC+2, Marcin Nowak wrote: > > > Somebody wrote eariler that `sql*` commands can be written as an external > app/package. They can't. Django internals must be fixed before this, or new > app must provide complete solution including sql generator like SE

Re: Fate of sql* management commands

On Tuesday, June 21, 2016 at 5:49:08 PM UTC+2, Marcin Nowak wrote: > > > > On Tuesday, June 21, 2016 at 4:00:51 PM UTC+2, Tim Graham wrote: >> >> No, it's not as simple as reverting the removal commit [0]. All the >> legacy schema generation methods are removed too [1]. >> > We don't want to ad

Re: Fate of sql* management commands

On Tuesday, June 21, 2016 at 4:00:51 PM UTC+2, Tim Graham wrote: > > No, it's not as simple as reverting the removal commit [0]. All the legacy > schema generation methods are removed too [1]. > We don't want to add them back > I know. > but rather use the SQL generation from the migrati

Re: Fate of sql* management commands

No, it's not as simple as reverting the removal commit [0]. All the legacy schema generation methods are removed too [1]. We don't want to add them back but rather use the SQL generation from the migrations system (SchemaEditor classes). Please read this thread closely and look at Andrew's pull

Re: Fate of sql* management commands

On Tuesday, June 21, 2016 at 3:28:26 PM UTC+2, Tim Graham wrote: > > Marcin, what are you hoping to accomplish with your latest mail? As > Aymeric said in another thread, repeated complaining is not going to help. > Sorry for that. I'm just overhelmed and tired of "fighting" with missing thin

Re: Fate of sql* management commands

Marcin, what are you hoping to accomplish with your latest mail? As Aymeric said in another thread, repeated complaining is not going to help. There's already an accepted ticket for this feature. If you want to be productive and helpful, pick up Andrew's patch and try to complete it. Alternative

Re: Fate of sql* management commands

On Monday, June 1, 2015 at 5:11:27 PM UTC+2, Andrew Godwin wrote: > > OK, so I've just gone ahead and done the initial work on this: > https://github.com/django/django/pull/4729 > > They shot not only in my head - http://stackoverflow.com/questions/35455706/equivalent-of-sqlall-in-django-1-9 G

Re: Fate of sql* management commands

OK, so I've just gone ahead and done the initial work on this: https://github.com/django/django/pull/4729 I'd appreciate testing by people to see how well that new sql command works; it's fine for me in dev here against a simple project but there's probably some edge cases. Nevertheless, it seems

Re: Fate of sql* management commands

As far as justification for dropping the old commands: 1. Andrew said earlier in the thread, "the sqlmigrate command will still get you SQL from migrations, though it sadly lacks the ability to take a range of migrations, optimise them down, and output the SQL for _that_ - that's probably the b

Re: Fate of sql* management commands

On Sunday, May 31, 2015 at 1:47:32 AM UTC+2, Tim Graham wrote: > > They were dropped as part of the removal of the old code that supported > syncing apps without migrations. > But you removed a feature, not just old code. In v1.8 (1.7 maybe?) this feature was broken (issue #24876) and it was c

Re: Fate of sql* management commands

They were dropped as part of the removal of the old code that supported syncing apps without migrations. https://github.com/django/django/commit/7e8cf74dc74539f40f4cea53c1e8bba82791fcb6 You could probably reimplement them at least to some extent using the new schema backends. By the way, I susp

Re: Fate of sql* management commands

Tim, I've just realised that there is no sql* commands in the newest Django. Generating SQL from models was very useful. Why do you decided to drop that functionality? Because of builit-in migrations? Can you just bring them back? Thanks. Marcin. On Friday, May 29, 2015 at 7:26:26 PM UTC+2,

Re: Fate of sql* management commands

Thanks, I didn't saw it. But I've found quick&dirty ad-hoc solution using monkey patching. Just include this snippet in project`s __init__: from django.core.management import sql def check_for_migrations_bypassed(*args, **kw): pass sql.check_for_migrations = check_for_migration_bypassed (T

Re: Fate of sql* management commands

There's a ticket waiting someone to implement what has been discussed: https://code.djangoproject.com/ticket/24481 On Friday, May 29, 2015 at 12:05:48 PM UTC-4, Marcin Nowak wrote: > > > > On Monday, March 30, 2015 at 1:58:02 AM UTC+2, Russell Keith-Magee wrote: >> >> >>> >>> *What is the new way

Re: Fate of sql* management commands

On Monday, March 30, 2015 at 1:58:02 AM UTC+2, Russell Keith-Magee wrote: > > >> >> *What is the new way to dump the sql schema of currently installed django >> appz ?* It'd maybe be worth that I provide a doc patch to inform users >> about it. >> *If there is none, is there an agreement to res

Re: Fate of sql* management commands

On 04/03/2015 02:30 PM, Collin Anderson wrote: > And the auto-generated in-memory migrations should work for tests too, > right? Well, that would depend on whether you have anything important in a RunSQL migration, or otherwise in a migration but not reflected in your model files. So, maybe. But i

Re: Fate of sql* management commands

And the auto-generated in-memory migrations should work for tests too, right? On Friday, April 3, 2015 at 2:34:23 PM UTC-4, Andrew Godwin wrote: > > > >> > An alternative would be to ignore migrations files, regenerate a fresh >> > set of migrations, and dump the corresponding SQL. >> >> I think

Re: Fate of sql* management commands

> > > > > An alternative would be to ignore migrations files, regenerate a fresh > > set of migrations, and dump the corresponding SQL. > > I think this approach would be much preferable to using the totally > separate legacy code path. Presented as a tool for debugging migrations > issues, and wit

Re: Fate of sql* management commands

On 04/03/2015 03:17 AM, Aymeric Augustin wrote: > 2015-04-02 23:03 GMT+02:00 Marc Tamlyn >: > > As far as I'm aware, we have some code paths which still work in 1.9 > which generate tables directly from the models. We use this when > running Django's own

Re: Fate of sql* management commands

2015-04-02 23:03 GMT+02:00 Marc Tamlyn : > As far as I'm aware, we have some code paths which still work in 1.9 which > generate tables directly from the models. We use this when running Django's > own test suite, and it is also used now by djangobench. I haven't looked > into exactly how to turn

Re: Fate of sql* management commands

Hello, sorry for the delay (I'm moving home), thanks for the detailed explanations, I've learned a lot about the new status of migrations, and I guess every django users might benefit from this "shift of canonical representation", that's why there shouldbe room for a proper introduction in django

Re: Fate of sql* management commands

As far as I'm aware, we have some code paths which still work in 1.9 which generate tables directly from the models. We use this when running Django's own test suite, and it is also used now by djangobench. I haven't looked into exactly how to turn this into logged SQL rather than run SQL but it sh

Re: Fate of sql* management commands

On 30 mars 2015, at 23:10, Carl Meyer wrote: > So it is not true that the Python models are the canonical > representation of your schema, and the SQL DDL is just a translation of > them. In fact, your migrations are the (only) canonical representation > of your schema, which may include things (

Re: Fate of sql* management commands

That is correct - RunPython and some other operations (definitely DeleteIndex) don't have single SQL statements that can be output. There's not much that can be done here, really - if you want to use SQL to set up databases, then you can't use RunPython to do it, you should just use migrations dire

Re: Fate of sql* management commands

Not sure about this but wouldn't "RunPython" actually keep you from getting an proven accurate result ? Even if we could imagine running the migration in a transaction and capturing the SQL that would be run, it would be dependent on the current data in the DB among other thing (could even be d

Re: Fate of sql* management commands

On Sun, Mar 29, 2015 at 4:57 PM, Russell Keith-Magee wrote: > It would probably be *possible* to refactor manage.py sqlall to use the new > table creation logic; but the question would then be "why do you want it"? Speaking from experience, I have found these commands to be a extremely helpful wh

Re: Fate of sql* management commands

Ah, but the point I'm trying to make is that they're not two separate notions at all. The current migrations system was deliberately designed in a way such that it is both - it's a representation of changes through time, sure, but it's also an entire statement of how the database is made. Migratio

Re: Fate of sql* management commands

Hi Pascal, On 03/30/2015 02:57 PM, Pascal Chambon wrote: > Thanks for your answers, > > l'm confused nonetheless, because their are two notions mixing up, here, > that we should probably separate: > > - the HISTORY of SQL schemas, aka "django/south migrations" > - the CURRENT STATE of SQL schema

Re: Fate of sql* management commands

Thanks for your answers, l'm confused nonetheless, because their are two notions mixing up, here, that we should probably separate: - the HISTORY of SQL schemas, aka "django/south migrations" - the CURRENT STATE of SQL schemas, that I'll call "ORM Models Dump" Let's leave the SQL data (and its m

Re: Fate of sql* management commands

I must also point out that the sqlmigrate command will still get you SQL from migrations, though it sadly lacks the ability to take a range of migrations, optimise them down, and output the SQL for _that_ - that's probably the best thing for us to aim towards, and will almost entirely recreate the

Re: Fate of sql* management commands

On Mon, Mar 30, 2015 at 1:36 AM, Pkl wrote: > Hello all, > > I've noticed that all sql* commands that were in django core management > have disappeared from the latest sources. > > However, even though Django now has builtin south-style migrations now, > these *sql** commands (especially sql-all)