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 dependant on the meteo, or random variables or anything)... And given that you can (as the doc says) use the scheme editor inside a RunPython migration, who knows what the proper SQL would be ? (again, I may be missing a point there) -- Joachim Jablon Le lundi 30 mars 2015 06:00:10 UTC+2, Andrew Godwin a écrit : > > 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 functionality of sqlall without actually being wrong (sqlall > doesn't understand things like data migrations or custom SQL sections of > migrations, and so will sadly be wrong in if you have anything like a > moderately complex migration set). > > The plus side is that it would be possible to do this sort of thing as a > third-party command/backport if we wanted to have it usable on 1.8 and even > 1.7 (the 1.8 feature set is frozen now, or I'd suggest quickly squeezing it > in). > > Andrew > > On Sun, Mar 29, 2015 at 4:57 PM, Russell Keith-Magee < > rus...@keith-magee.com > wrote: > >> >> 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) were priceless to debug >>> differences between the models and the actual DB schema. >>> Especially as long as some django apps haven't caught up with all these >>> recent changes - I myself ended up with missing tables after scrupulously >>> following upgrade instructions, with "manage.py migrate" saying "all is >>> fine". >>> >>> *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 restore at least sqlall and >>> sqlclear ?* >>> >> >> No, there isn't :-) >> >> Also what was the reasoning behind, on the first, place, blocking access >>> to these utilities in django1.7 (they seemed to work, when I forced them), >>> and now removing them ? A simple warning about the new "migrations" stuffs >>> (or a "--force" argument) would most probably have sufficed to prevent >>> improper usage of these sql* commands, while letting django users getting >>> the info they need to move forward, wouldn't it ? >>> >> >> Right now, there are two (almost) completely independent implementations >> of SQL table generation logic: >> >> * The legacy version, used by syncdb, sqlall, et al >> >> * The new version, used by migrate. >> >> In the past, there was a good reason for sqlall to exist - you needed to >> be able to run syncdb and create tables. The only time you ever called >> "CREATE TABLE" was when a table was fresh, and after that, you never issued >> any command related to the table schema. It didn't hurt anyone to allow >> sqlall to generate "what would the CREATE TABLE be if we had clean >> databases", and it was at least partially useful as a migration assistant, >> so the sqlall functionality was available. >> >> In the era of migrations, there's still a need to do a CREATE TABLE, but >> the table creation logic is a lot more complex, because it's not *just* a >> CREATE TABLE that is needed; all the ALTER TABLE statements are needed to >> add/remove columns as well. >> >> 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"? manage.py migration *should* be handling all your table creation and >> migration functionality, so the need to manually diff a schema shouldn't >> exist. If you've hit problems with "manage.py migrate" *not* identifying >> migrations, then that's a much bigger problem, and one that needs to be >> reported as a bug - because it's a huge bug. Anything you can do to narrow >> down the situation that led to the problems you've observed would be very >> helpful. >> >> Yours, >> Russ Magee %-) >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-develop...@googlegroups.com . >> To post to this group, send email to django-d...@googlegroups.com >> . >> Visit this group at http://groups.goog
ModelManager behaviour for Proxy Models
I am not sure about the current development branch but last time I checked, performing query on proxy models by default considers all the objects of the parent/base class. If anyone is to consider only the objects of that class, he has to implement a custom modelmanager for that and use it. In most of my projects I use proxy models and I always have to create this ModelManager. My suggestion is - Can we put a new config option 'disciminitator' property in the class Meta of django.db.models.Model, so that whenever a user creates a proxy model, he has to mention this property and this will be the a column in that table and the class name will be saved in that column automatically when saving or updating objects. And when doing query with proxy models, this columns will be automatically added in the filter so that developers will not need to create a custom ModelManager for their proxy model. Please waiting for others feedback. Best, Mahmud -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/fc40cc09-fe81-4f27-a6aa-5387543cd279%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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 directly (as they were intended). Andrew On Tue, Mar 31, 2015 at 12:20 AM, Joachim Jablon wrote: > 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 dependant on the meteo, or random variables or anything)... > > And given that you can (as the doc says) use the scheme editor inside a > RunPython migration, who knows what the proper SQL would be ? > > (again, I may be missing a point there) > > -- > Joachim Jablon > > > Le lundi 30 mars 2015 06:00:10 UTC+2, Andrew Godwin a écrit : >> >> 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 functionality of sqlall without actually being wrong (sqlall >> doesn't understand things like data migrations or custom SQL sections of >> migrations, and so will sadly be wrong in if you have anything like a >> moderately complex migration set). >> >> The plus side is that it would be possible to do this sort of thing as a >> third-party command/backport if we wanted to have it usable on 1.8 and even >> 1.7 (the 1.8 feature set is frozen now, or I'd suggest quickly squeezing it >> in). >> >> Andrew >> >> On Sun, Mar 29, 2015 at 4:57 PM, Russell Keith-Magee < >> rus...@keith-magee.com> wrote: >> >>> >>> 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) were priceless to debug differences between the models and the actual DB schema. Especially as long as some django apps haven't caught up with all these recent changes - I myself ended up with missing tables after scrupulously following upgrade instructions, with "manage.py migrate" saying "all is fine". *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 restore at least sqlall and sqlclear ?* >>> >>> No, there isn't :-) >>> >>> Also what was the reasoning behind, on the first, place, blocking access to these utilities in django1.7 (they seemed to work, when I forced them), and now removing them ? A simple warning about the new "migrations" stuffs (or a "--force" argument) would most probably have sufficed to prevent improper usage of these sql* commands, while letting django users getting the info they need to move forward, wouldn't it ? >>> >>> Right now, there are two (almost) completely independent implementations >>> of SQL table generation logic: >>> >>> * The legacy version, used by syncdb, sqlall, et al >>> >>> * The new version, used by migrate. >>> >>> In the past, there was a good reason for sqlall to exist - you needed to >>> be able to run syncdb and create tables. The only time you ever called >>> "CREATE TABLE" was when a table was fresh, and after that, you never issued >>> any command related to the table schema. It didn't hurt anyone to allow >>> sqlall to generate "what would the CREATE TABLE be if we had clean >>> databases", and it was at least partially useful as a migration assistant, >>> so the sqlall functionality was available. >>> >>> In the era of migrations, there's still a need to do a CREATE TABLE, but >>> the table creation logic is a lot more complex, because it's not *just* a >>> CREATE TABLE that is needed; all the ALTER TABLE statements are needed to >>> add/remove columns as well. >>> >>> 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"? manage.py migration *should* be handling all your table creation and >>> migration functionality, so the need to manually diff a schema shouldn't >>> exist. If you've hit problems with "manage.py migrate" *not* identifying >>> migrations, then that's a much bigger problem, and one that needs to be >>> reported as a bug - because it's a huge bug. Anything you can do to narrow >>> down the situation that led to the problems you've observed would be ver
(Model)formsets, passing custom kwargs to form and _construct_form
Hi all, I've quite often found myself needing to pass custom kwargs to each form within a formset (common parameter for all forms). A common pattern for this is implementing a custom BaseMyModelFormSet(BaseModelFormSet), overriding __init__ and then passing the custom argument via _construct_form, hereby overriding/extending a private method. Would it be a good idea to add a form_kwargs attribute on the BaseFormSet class, and pass those arguments by default within _construct_form? This would reduce code verbosity so that you only need to set form_kwargs, either on class definition of the custom BaseFormSet, or dynamically in the custom formset class' __init__. This would prevent overriding a private method. An alternative approach is using functools' partial/curry, but apparently this may cause trouble with the order of arguments and passing dynamic values (such as request.user). I'd love to hear any feedback on this, if other people like it I might give the implementation a go on the Djangocon EU sprint. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8011c21f-8384-4ef7-93bf-1e1f01769d47%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: ModelManager behaviour for Proxy Models
Hi Mahmud, On Tuesday 31 March 2015 16:17:52 mahmudul islam wrote: > I am not sure about the current development branch but last time I checked, > performing query on proxy models by default considers all the objects of > the parent/base class. If anyone is to consider only the objects of that > class, he has to implement a custom modelmanager for that and use it. In > most of my projects I use proxy models and I always have to create this > ModelManager. > > My suggestion is - Can we put a new config option 'disciminitator' property > in the class Meta of django.db.models.Model, so that whenever a user > creates a proxy model, he has to mention this property and this will be the > a column in that table and the class name will be saved in that column > automatically when saving or updating objects. And when doing query with > proxy models, this columns will be automatically added in the filter so > that developers will not need to create a custom ModelManager for their > proxy model. > I don't know much about your different projects, but your description makes it seem like you are Doing It Wrong™. If your proxy models do not have enough information to select only the "right" rows, then perhaps instead of a concrete parent with proxy submodels you should have used an abstract parent with concrete submodels; then you'd get your "right rows for the proxy" queries for free, and they would also be more efficient. However, even if I'm wrong -- I think you don't really need changes in Django to implement the essence of your idea. You can write base classes for models and managers providing this functionality (just put your 'discrimnator' attribute directly in the model class instead of in Meta) and use them instead of Django's default ones. Doing this would be a great way to show that the idea works, and maybe popularize it. Shai.
Re: Overlap between Func and Transform
Also, found the patch I wrote: https://gist.github.com/jarshwah/a541857db195f0486b9e Instead of multiple subclasses, perhaps Func could take on some of the functionality of transform directly, but that makes no sense for > 1 arity functions. A nice design should be able to be found. On Thursday, 26 March 2015 05:28:51 UTC+11, Anssi Kääriäinen wrote: > > Transforms are just single argument expressions available using lookup > strings. The biggest complication is that Transforms have slightly > different API to expressions. > > I don't see a reason why transforms couldn't be a special case of > expression. There are some API incompabilities, but they should be solvable. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/efda77ae-033d-41d4-a878-fa32ab3dd2c7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
