Re: Merging Schema Alteration branch

and this branch deviating even more. Andrew On 10 Aug 2013 10:22, "Florian Apolloner" wrote: > On Saturday, August 10, 2013 4:41:28 AM UTC+2, Russell Keith-Magee wrote: >> >> Say… Andrew… there's this guy on a black horse at my front door… says his >> name is &qu

Re: Custom prefetches (#17001)

I'd love to see this solved. I'm not sold on the API, but then again I've yet to see a single suggested API for this problem that I actually like. I showed you this a little while ago, you had some reservations with my idea, but I figured I might as well add it to the conversation anyway: https://

Re: Custom prefetches (#17001)

ugust 23, 2013 6:25:42 PM UTC+3, Andrew Ingram wrote: >> >> I'd love to see this solved. I'm not sold on the API, but then again I've >> yet to see a single suggested API for this problem that I actually like. >> >> I showed you this a little while ago, you h

Re: FormSetView and ModelFormSetView

Having basically built all of the views in question, I agree with Russell. By having multiple form classes in a view itself, you're essentially pulling validation logic out of the form and into the view where it doesn't belong. A view shouldn't be concerned with the specifics of validation, it shou

1.7 Release Schedule

up, otherwise this is our final schedule! Andrew -- 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

Re: 1.7 Release Schedule

aiting for, it would be a poor move to release with it unpolished or buggy. Don't worry, hopefully we'll have a mostly stable beta people can start developing newer projects on. Andrew -- You received this message because you are subscribed to the Google Groups "Django developers"

Re: SchemaEditor Enhancements

field where if the _sql attribute is set to None we instead call an overrideable method. Andrew On Fri, Dec 20, 2013 at 7:54 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > > Trunk is still open for all 1.7 changes; 1.7 alpha is currently planned > for mid January, wh

Re: South data-migration and custom save() method

working as originally written if you later change what the save method does). Andrew On Fri, Dec 20, 2013 at 4:15 PM, Val Neekman wrote: > South (latest) has a limitation where it ignores a custom save() method in > the model class. > > I am wondering if that is going to be true fo

Re: South data-migration and custom save() method

It won't load initial_data fixtures - those are being deprecated for migrated apps - but you could still call loaddata with a custom one, I guess. I'd personally recommend moving away from fixtures and just instantiating objects directly using the ORM inside data migrations. Andrew O

Re: App-loading reloaded

away - and while I'd like to see this land in 1.7, if it misses that date it's out; the release is already complex enough as it is to have a behind-time complex feature drag it back further, and now your dedicated time on this is over it's going to move slower. Andrew * By "al

Re: Django 1.7 - Named migration directory

etting per app :) Andrew On Mon, Dec 23, 2013 at 11:57 PM, Val Neekman wrote: > I am wondering if it would be a good idea for a django app to name its > migration directory and if nothing is provided then the name would default > to 'migrations'. > > The case: (let's

Re: Schema editor changes feedback request

length stuff. As for not being able to add autoincrement to an existing column - I'd say it's fine for you to state it's not supported and just raise a hard error when it happens. The situation is very rare and I doubt a lot of people will run into it. Andrew On Sat, Jan 4, 2014 at

Migrations and swappable models/AUTH_USER_MODEL

as swapped out (so ForeignKey("auth.User") automatically becomes ForeignKey("myapp.CustomUser") internally. Now, I prefer the cleanliness of 2), but I suspect there was a reason this wasn't done when swappable models were first introduced; that said, I haven't s

Re: Migrations and swappable models/AUTH_USER_MODEL

u still have to manage moving the data into that table yourself, and I'm not sure we can do it any other way. Migrations sees you changing the user model as an actionable change, since as far as it's concerned you changed a load of "to" arguments of foreignkeys when you ch

Re: Migrations and swappable models/AUTH_USER_MODEL

solution that I can see which somehow gives something to both sides - 1b - makes it really, really easy for third-party apps to ship broken migrations and not know about it, and I don't like that. I think we have to sacrifice being able to tell that the user model was changed in favour of havin

Re: Migrations and swappable models/AUTH_USER_MODEL

OK, I like that approach Russ - an inverted 1b. It'll be a bit harder to explain in the docs, but it won't catch anyone out unawares, which is the key thing. Andrew On Thu, Jan 9, 2014 at 1:28 AM, Russell Keith-Magee wrote: > > > > On Thu, Jan 9, 2014 at 12:04 AM, Andrew

Re: Migrations and swappable models/AUTH_USER_MODEL

(".", 1)[0], "__first__") - we already have the __first__ special migration name which resolves to the start of any app (it's used for depending on apps with no migrations at the moment, in case they gain them in future) Andrew On Sat, Jan 11, 2014 at 9:43 PM, Shai Berg

Re: Must a Django Database Support Migrations?

Bear in mind that the ./manage.py sqlmigrate command lets you turn migrations into SQL scripts to send to your DBA (and many DBAs appreciate having some SQL they can work from - I know ours do), so having the ability to make that SQL is useful even if Django never runs it. Andrew On Wed, Jan 22

Re: Must a Django Database Support Migrations?

BaseDatabaseSchemaEditor on par with BaseDatabaseCreation's ability to > create/delete schema objects. > When you say "provided", what do you mean? The current base SchemaEditor provides a lot and once we've fixed up some of the issues you raised with the MSSQL patch

Re: Must a Django Database Support Migrations?

nd if it was just an ADD COLUMN with NULL, then I'd let Django do it anyway as I know that's instantaneous and lock-free, and Django handles all the transaction management around migrations so it can roll back if things error). Andrew -- You received this message because you are subscrib

Re: Syncdb issue

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, &

Re: Django 1.7 data migrations?

Hi Kent, The documentation is not yet complete, hence your confusion. There is indeed provision for data migrations in the new system, with an operation called RunPython - I'll see if I can get documentation up for it this week. Andrew On Mon, Feb 10, 2014 at 7:14 PM, Kent Engström

Re: ImportError: cannot import name actions

Got this while tried to laucnh Djangos test suite on fb1e3435a4d7e0265f19a1a9f130c9485fb8dfe9 On Tuesday, October 15, 2013 4:56:56 PM UTC+4, rok wrote: > > I have recently been testing the 1.6b4 tag with a new app we are writing, > using apache and wsgi. However, I could not get rid of the follo

Re: Django 1.7 data migrations?

To follow up on this, I've just pushed some documentation for this up - you can see it at https://docs.djangoproject.com/en/dev/topics/migrations/#data-migrations Feedback welcome! Andrew On Mon, Feb 10, 2014 at 7:29 PM, Kent Engström wrote: > Andrew Godwin writes: > > Hi Ken

Re: Migrations and System Checks

context for the checks - things like "this check is only for interactive runserver sessions" - then it would fit there. Perhaps we do, I've not looked into checks too much. Andrew On Wed, Feb 12, 2014 at 10:28 PM, Mark Lavin wrote: > Last weekend I set out to fix https://cod

Re: [GSOC] Improving the Test-Suite

/msgid/django-developers/d5f33c9e-89f5-4299-acdc-8f1456d04109%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. diff --git a/tests/conftest.py b/tests/conftest.py new file mode 100644 index 000..ed65e84 --- /dev/null +++ b/tests/conftest.py @@ -0,0 +1,26 @@ +# codin

Re: `prefetch_related` for non-homogenous data and "weak" lookups through GFKs

Ive made workaround for this case as external app<https://bitbucket.org/andrew_pashkin/django-deep-prefetch> . On Sunday, February 9, 2014 12:14:32 AM UTC+4, Andrew Pashkin wrote: > > With GenericForeignKey functionality, it is possible to refer to > arbitrary model. Let's a

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

> > >>1. Distributed testing (speed up, especially on multi-core machines), >>Line Coverage, etc using plugins >> >> How would this work? We still have shared resources like the database > where you can't just run 10 Test against in parallel. > There is django plugin for py.test

1.7 Beta Feature Freeze

patch reviewing, or just making a project or test that reproduces the issue): https://code.djangoproject.com/query?status=!closed&severity=Release+blocker&order=priority I'll be working on migrations issues over the weekend, and hopefully I'll have enough time to get them all. An

Re: [GSoC 2014 proposal]. Improving admin translation and formalizing Meta objects.

The problem is actually exists, I also want to find a way, how to rid my cleints of that crazy wording in admin-site. I've found promising package - pymorphy2 (https://github.com/kmike/pymorphy2), it can find grammatical information for words and translate words to needed forms. So all what is n

Re: [GSoC 2014 proposal]. Improving admin translation and formalizing Meta objects.

Proof of concept for pymorphy solution: https://gist.github.com/StillNewb/9703843 On Saturday, March 15, 2014 9:20:24 PM UTC+4, Алексей Сидаш wrote: > > Hello > > Yes, Adam Mesha seems to be right. The problem of translation is very > complicated. > I see only one solution, all the text in admin

Re: Migrations in Django 1.7 make unit testing models harder

#x27;t be in there - as I said, it's already part of the deprecation cycle. Andrew On Tue, Mar 25, 2014 at 10:21 AM, Bernie Sumption wrote: > Hi Django devs, > > I've just started a new project in 1.7b, and the development experience > working with unit tests on models is

Re: Migrations in Django 1.7 make unit testing models harder

1.8 (1.7 is too frozen now to add it IMO). Andrew On Tue, Mar 25, 2014 at 12:01 PM, Shai Berger wrote: > On Tuesday 25 March 2014 20:36:39 Marc Tamlyn wrote: > > Do we have an equivalent of south's --update? This would mean you don't > get > > many files. We don't

Re: Migrations in Django 1.7 make unit testing models harder

;s relatively easy to just run makemigrations to get new migrations for models, especially now it just does the whole project at once. Unless I can see this framed as being a significant impact to development process, I'm not going to hold up the release because of it... Andrew On Tue, Mar 25, 2014 at 1:5

Re: Migrations in Django 1.7 make unit testing models harder

On Tue, Mar 25, 2014 at 4:02 PM, Florian Apolloner wrote: > On Tuesday, March 25, 2014 9:12:42 PM UTC+1, Andrew Godwin wrote: >> >> So, the functionality whereby you can have apps which do not use >> migrations (i.e. that use the old creation backends) is meant to go away

Re: Migrations in Django 1.7 make unit testing models harder

ve forever ruined the migration tracking on it). Would that work? Or do you want to do this on apps which are already several migrations along? (If that's the case, I suspect we might have to look at re-introducing --update, which is going to be near-impossible to do before release with the n

Re: Migrations in Django 1.7 make unit testing models harder

sh a baseline, would you say that adding an "--update" command to makemigrations - which rolls the changes into existing migrations if it can - would solve your problem here? If that's the case, we can work towards that and figure out something simpler for the meantime. Andrew On

Re: Migrations in Django 1.7 make unit testing models harder

think there's a good solution that Django core can implement effectively. This reminds me of when people used to ask me to automatically stop their developers writing conflicting migrations - the solution varies from company to company and often isn't technical but just education or communica

Re: Migrations in Django 1.7 make unit testing models harder

g part of your codebase. Hell, you can alias together makemigrations and test if you want, that'll save you the typing. This might make a few more migrations than normal, but you could quickly point out that squashmigrations exists to deal with this problem and move on. Andrew On Sat, Mar 2

Re: Migrations in Django 1.7 make unit testing models harder

trings for you then. If not, open a bug report! Andrew On Sun, Mar 30, 2014 at 5:13 AM, Shai Berger wrote: > On Sunday 30 March 2014 15:08:17 Harry Percival wrote: > > Ah, so the reason I was confused is because it *looks* like the default > is > > the empty string, becaus

Re: Migrations in Django 1.7 make unit testing models harder

Yes, you can - the "migrations or not" switch is currently "is there a migrations directory", but bear in mind this will eventually turn from "use the old way" to "ignore it completely", probably also in 1.9. Andrew On Mon, Mar 31, 2014 at 4:15 PM, Harr

Re: Proposal: Database Constraints

constraints that are SQL themselves; there's no real benefit to abstraction here, and removing it doubtless removes a lot of code and bugs. Otherwise, I think I'd be +0. Andrew On Tue, Apr 1, 2014 at 4:07 AM, schinckel wrote: > Some years ago, I discussed adding databas

Re: Proposal: Database Constraints

this - there'll be some kind of field method that SchemaEditor looks for for its extra SQL to run. I agree, though, Anssi - if we have that in there then it's a lot easier. Andrew On Wed, Apr 2, 2014 at 7:10 AM, Anssi Kääriäinen wrote: > On Wednesday, April 2, 2014 6:58:22 AM UTC+

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

Some Pytest advocacy: 1) Pytest has convenient tests collection options - you can just specify folder to run all tests in it. It is also possible to filter tests by regex, and select specific ones. 2) PyUnit: class MyTestCase(TestCase): def test_something(self): expected_content = ..

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

discuss cases where Pytest cant handle (or handle with convennience) what PyUnit can and vice versa. On 06.04.2014 21:02, Chris Wilson wrote: Hi Andrew, I'm not a Django core contributor but just a user and occasional patcher. I submit some comments on this proposal in the hope that they

Re: Wrong translation in Brazillian portuguese

According to https://code.djangoproject.com/wiki/Version1.7Roadmap, the translation string freeze is not until the 1st of May, so it should be. -- Andrew On Mon, Apr 7, 2014 at 10:45 AM, Bruno Ribeiro da Silva < bruno.dev...@gmail.com> wrote: > Hi everyone, > > I found a wrong

Re: DEPs: Django Enhancement Proposals

Who is responsible then for deciding what the conclusion of the discussion was? If there is no such person, how does the process handle the case when people talk past each other and don't actually come to a conclusion? On Mon, Apr 14, 2014 at 2:22 PM, Michael Manfre wrote: > I think there would

Re: Data Migrations and Testing

Hi Christian, Can you explain your situation more, and perhaps give us some example files or console output? When you run tests they should run through all the migrations first, so any initial data should get loaded in before tests begin. Andrew On Thu, Apr 17, 2014 at 1:16 PM, Christian

Re: Data Migrations and Testing

Perhaps we should look into deprecating flushing? It's not a behaviour that can be easily replicated any more, as it relied on the old system of one-shot schema and load a single file, but it's also kind of crucial to non-transactional tests... Andrew On Fri, Apr 18, 2014 at 7:56 AM, Chri

Re: Data Migrations and Testing

e in memory and then spool out to disk if it gets too big. Andrew On Sat, Apr 19, 2014 at 5:20 AM, Andrey Antukh wrote: > 2014-04-19 14:15 GMT+02:00 Anssi Kääriäinen : > > On 04/19/2014 10:52 AM, Anssi Kääriäinen wrote: >> >> Getting dump-and-reload support for 1.7 seems hard

Re: Data Migrations and Testing

tures). I will try and remove that first flush before tests start, though, which would at least let you use the data inside normal TestCases on transactional DBs, though I fear removing it might be too backwards-incompatible. Andrew On Sun, Apr 20, 2014 at 12:23 AM, Anssi Kääriäinen wrote: >

Re: Data Migrations and Testing

like to have started the Creation deprecation cycle this release, but it's probably fine if we let that slip a release (it's going to be harder to remove than many other features). Migrations will hopefully drive the adoption of SchemaEditor by developers and third-party backends anyway. An

Re: Data Migrations and Testing

hink that's the best solution we have here, as it "emulates" the right behaviour on databases with no transactions and should do the right thing for TransactionTestCases. I've opened a ticket here: https://code.djangoproject.com/ticket/22487 Andrew On Tue, Apr 22, 2014 at 2:02

Re: Field.get_default() returning dict instance causing migration to fail

bug in Django. If you could file it in the issue tracker that'd be great; I'll get around to dealing with it when I get to my free time on Wednesday. Andrew On Mon, May 5, 2014 at 4:35 PM, Martin Tiršel wrote: > Hello, > > I just installed 1.7 (pip install git+ > htt

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

Another advantage of Pytest is its ability to launch tests written in all styles - PyUnit, Nose, and Pytest own style. Recently I understood that it is a good practice to launch tests not only for project, but for all packages it uses before deployment - to ensure that nothing is broken (like mi

Re: django-firebird backend: migrations and NULL fields

change completely as we're trying to release 1.7. What we could do is change those NULL and NOT NULL strings to be defined on the schema editor class itself, and then you could set sql_null_suffix = "" or similar - do you think that would be a reasonable approach? Andrew On Wed, M

Re: django-firebird backend: migrations and NULL fields

Hmm, I'm not sure about adding more features, but it might be cleaner... Andrew On Wed, May 14, 2014 at 8:00 AM, Jeremy Dunck wrote: > How about adding a flag to Operations? implied_null, perhaps. > On May 14, 2014 7:52 AM, "Andrew Godwin" wrote: > >> Hi, &

Re: django-firebird backend: migrations and NULL fields

Let's go with a feature for this then. Maxi, did you want to submit a patch, or do you want me to add it at some point next week! Andrew On Wed, May 14, 2014 at 6:27 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > For what it’s worth, I recently added a

Re: Release of 1.7 news for podcast?

Given that I'm still abroad at this point, I'm not as productive as I can be at the moment for health reasons, and the number of release blockers seems to keep growing, I wouldn't be able to put on a date on it. At least a month at this point I suspect, but hopefully sooner. Andre

Re: Schema tests: delete_tables

on the backend. However, I disagree that it is a release blocker. We're inevitably going to have a 1.7 point release anyway, 1.7.0 is not some time where everything like this gets clad in stone, and these tests are only for the backends themselves, not for end-users to run. Andrew On Tue,

Re: django-firebird backend: migrations and NULL fields

t it to True and you should get the behaviour you need. Andrew On Fri, May 16, 2014 at 10:00 PM, Maximiliano Robaina wrote: > > > El viernes, 16 de mayo de 2014 09:49:15 UTC-3, Andrew Godwin escribió: > >> Let's go with a feature for this then. >> >> Maxi, did you

Re: Schema tests: delete_tables

ps this should be in 1.7, perhaps it shouldn't; without input from you and others it's just left to me to decide, and I always tend towards a "ship early, ship often" style, sometimes too far (as South users sometimes see). Andrew -- You received this message because

Re: Loading fixtures once for each TestCase to improve running time

Aymeric says, savepoints are probably the answer here, and that ticket he linked seems to be partway there.. Andrew On Thu, Jun 12, 2014 at 6:40 AM, Christian Schmitt wrote: > Yeah as said that ticket resolved the issue that you can't test data > migrations, so for now on you cou

Re: Migrations and Reusable Apps

ing refactor, the changes to custom fields, and a few other things. I might leave an open offer of help upgrading from myself after the release to any app maintainers to try and smooth that process along. Andrew On Tue, Jun 17, 2014 at 9:36 AM, Trey Hunner wrote: > -BEGIN PGP SIGNED MESS

Re: django-firebird backend: migrations and NULL fields

Thanks Tim. I sometimes just forget to run the backport script... Andrew On Thu, Jun 19, 2014 at 8:04 AM, Tim Graham wrote: > Backported in 30d8b95139a1fa3070f3b112115e624ffcf8e555, thanks for the > reminder. > > > On Thursday, June 19, 2014 9:36:54 AM UTC-4, Maximilian

Re: Data Migrations and Testing

opt-in not opt-out). Did you turn that on and it's still failing? Andrew On Sat, Jun 21, 2014 at 5:07 PM, Rafał Pitoń wrote: > Ticket claims this is fixed, but as I've moved my project to Django 1.7, > I've seen story from OP's mail repeat. My migrations create tables,

Re: [1.7-RC] Using coverage with migrated app slow down test-suite execution by 6 times.

ould be no worse than syncdb) - Coverage seems to run 6-7x slower. I'm not sure if this is migrations, app-loading, system checks or one of the many other changes made from 1.6 to 1.7; I would be interested to hear any other reports of this issue. Andrew On Tue, Jul 8, 2014 at 3:55 AM, Sta

Re: [1.7-RC] Using coverage with migrated app slow down test-suite execution by 6 times.

n the slow migration first, as that's a more general issue. Andrew On Wed, Jul 9, 2014 at 10:24 AM, Christian Schmitt wrote: > HI, > > Currently we developing a Greater Application with many Apps and Models > per App that are referenced through the Apps. We have like 30+ Models and

Re: Problem migrating from South to Django migrations for Linux distributions

gration mode (which won't destroy any tables, but will fail to apply any table alterations). Also, what are the applications in particular that this will be a problem for? I'm curious to know what Django + South things Debian is shipping these days. Andrew On Thu, Jul 24, 2014

Re: Overriding AppConfig.get_model(s)

Migrations instantiate their own copies of AppConfig and Apps and run from those, so you won't be able to affect them by overriding methods. If you want to exclude models from migrations use router.allow_migrate. Andrew On Fri, Jul 25, 2014 at 11:59 AM, Nick Sandford wrote: > I

Re: Overriding AppConfig.get_model(s)

I don't think there's a way you can do this with migrations. You're not supposed to be able to change them at runtime based on settings; that was the cause of most of our bugs with swappable models. Andrew On Fri, Jul 25, 2014 at 12:48 PM, Nick Sandford wrote: > Ahh ok, tha

Re: Overriding AppConfig.get_model(s)

ns, then go and tie the model's managed option to the setting - that should do what you want - but people are going to get real confused when they change the setting and the table isn't made for them. Andrew On Fri, Jul 25, 2014 at 1:17 PM, Nick Sandford wrote: > Isn't tha

Re: Overriding AppConfig.get_model(s)

on-db and now it has a migration applied that no longer exists on disk. Andrew On Fri, Jul 25, 2014 at 1:38 PM, Nick Sandford wrote: > Managed might be the ticket then. I don't think it's too surprising to the > user who configures a cache or file session backend that no d

Re: SchemaEditor + DatabaseConnection

didn't want to duplicate code; we'll move that code over eventually) Andrew On Mon, Jul 28, 2014 at 2:33 AM, Tim Graham wrote: > FWIW, I may have closed that PR prematurely. I didn't realize SchemaEditor > still relied on DatabaseCreation and I'm not sure what the final >

Re: getting django 1.7 out the door

Solved it now! For those interested, deconstruct() was not including related_name, with the result that both a ForeignKey and a ManyToMany had the same related_name, and it turns out that Django really doesn't like this, and there's a reason model validation complains about it. Andre

Re: Gotcha in apps and migrations handling?

It's not intended behaviour, it might be a bug with app loading or migrations or it might just be a circular import issue. Could you open a ticket with your test case on the Trac? Andrew On 16 Aug 2014 14:15, "Rafał Pitoń" wrote: > I have noticed something today as I'v

Re: 1.7 release?

f apps. These are the sorts of things I would have released South with and fixed in a later release, but we hold Django to a higher standard. Andrew On Tue, Aug 19, 2014 at 8:40 AM, Collin Anderson wrote: > I'm not a core developer, but here's the current situation as far as I can

Re: Django 1.7 migrations and third-party imports

t's a lot easier to throw away old migrations (ones with custom fields that are no longer used) and start afresh now. Andrew On Tue, Sep 9, 2014 at 2:27 PM, Carl Meyer wrote: > Hi Greg, > > On 09/09/2014 03:00 PM, Greg Brown wrote: > > Moving over to the new migrations, I n

Re: Django 1.7 migrations and third-party imports

projects using >> South shows it's not really a problem. >> >> I agree that it'd be good to explicitly document this - I'll have a look >> at that now. >> >> Greg >> >> >> >> On Wednesday, 10 September 2014 09:30:47 UTC+12, A

Re: Unifying locale time formats

raham also pointed me to a part of the documentation that may be helpful: https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist Hope that helps, Andrew -- You received this message because you are subscribed to the Google Groups &q

Re: Two proposals for the Django Code of Conduct.

to say as much on the DCoC webpage (rather than or alongside "rules")? - The issue of Free Speech (I'm assuming the American definition), has been invoked a few times. In what way would this new clause inhibit Free Speech? Thanks you, Andrew -- You received this message

Re: Migration challenges

I'm still on holiday, but just wanted to quickly feed back on some of these: On Wed, Sep 24, 2014 at 8:54 AM, Shai Berger wrote: > Hi all, > > I gave a talk to a local user-group about the migrations in 1.7, and some > people in the audience raised things they would like to be able to do, and >

Re: South's --update equivalent for Django 1.7 migrations

on this yet, but if someone wants to take it on I'm happy to provide guidance and code review. Andrew On Wed, Oct 8, 2014 at 10:48 PM, Petri Lehtinen wrote: > On Thursday, October 9, 2014 12:01:45 AM UTC+3, Curtis Maloney wrote: >> >> Since I didn't know about the upda

Re: South's --update equivalent for Django 1.7 migrations

Either is fine, depends on the dynamic you want to take. Direct to me will probably get more attention; I don't read -developers nearly as often as I should. Andrew On Thu, Oct 9, 2014 at 12:03 AM, Petri Lehtinen wrote: > Andrew Godwin wrote: > > --update was a feature contri

Re: permissions and groups data migration

As the ticket suggests, you can call the function to create permissions yourself in the data migration, and then you can assign them as normal. There's no need to use fixtures (in fact, migrations are better without fixtures, as there's no easy way to load them). Andrew On Tue, Oct 14,

Re: A new approach for migrations?

lows people to run the diff (that's what the Autodetector and makemigrations does), and then review and refine its output first before preserving the final, polished migrations on disk in a distributable format that follows Django's app-based structure. I hope that helps. Andrew On Thu

Re: A new approach for migrations?

s known to fail is swappable models (so AUTH_USER_MODEL), as we can't predict the value of it. Andrew On Thu, Oct 16, 2014 at 5:15 PM, Shai Berger wrote: > Hi Uri, > > On Friday 17 October 2014 01:30:10 Uri P wrote: > > Thanks Andrew for enlightening me. That was helpful. >

Re: sys.exit(1) from makemigrations if no changes found

rising compared to grep, there are many other commands with different exit codes one could draw parallels to; I'm not sure being consistent with a very different utility is a worthwhile cause). Andrew On Tue, Oct 28, 2014 at 6:22 PM, Tim Heap wrote: > Hi all, > > I have create

Re: Add ability to show the migration plan (#23359)

on migrate. I don't really mind which way you go, to be honest; both seem like sensible places. Other people might have stronger opinions. Andrew On Wed, Oct 29, 2014 at 4:44 PM, Markus Holtermann wrote: > Hey folks, > > A few weeks ago I opened a ticket ( > https://code.djang

Re: Setting database default values in migrations (postgres)

e users will have entirely the wrong value in that field whenever they insert rows but no errors to tell them about it (and if you don't have other database users than Django, why do you need the defaults in there in the first place?) Andrew On Thu, Oct 30, 2014 at 8:47 AM, Peter Coles wrote

Re: Setting database default values in migrations (postgres)

ly invalid default in there. If this does happen, I'd probably want some way to declare what defaults to keep. (South actually used to have this with a keep_default option on the add_column method but it was kind of unmaintained) Andrew On Thu, Oct 30, 2014 at 1:45 PM, Peter Coles wrote: &

Re: Setting database default values in migrations (postgres)

mean that non-Django code trying to add rows will start getting integrity errors when it tries to add the rows, for a non-obvious reason. I'm just not sure of the use case of database defaults in this kind of scenario. Andrew On Thu, Oct 30, 2014 at 2:51 PM, Peter Coles wrote: > Intere

Re: Setting database default values in migrations (postgres)

o tries to work out if the default is safe or not. Andrew On Fri, Oct 31, 2014 at 9:35 AM, Jon Dufresne wrote: > On Fri, Oct 31, 2014 at 6:48 AM, Shai Berger wrote: > > Peter, you said you're "interested in getting database migrations to > support > > setting d

Re: Sounding out for GSoC 2020.

proper story and hooks for running Django as a service (i.e. outside of a traditional HTTP request/response cycle) And some ludicrous projects I'd still consider: * Evented/event-sourcing database work on top of the ORM * A GraphQL-to-ORM mapper Andrew On Tue, Dec 10, 2019 at 8:25 AM Ca

Re: Sounding out for GSoC 2020.

areas (the current set in djangobench are weak in, say, the HTTP-serving-speed area) and then run them against pull requests and each release, so we can make sure Django doesn't get slower while nobody is looking. I'm sure there's a lot more, but these are top of mind at the moment! A

Re: Psycopg3 Redesign

I am particularly excited for native async support arriving - that's something I'd love to have and ship support for from our side when it's done. The rest looks quite sensible too. Andrew On Wed, Mar 11, 2020 at 3:39 AM Jure Erznožnik wrote: > His proposed changes look aweso

Re: New Merger nomination.

I also vote in favour of Claude becoming a Merger! Andrew On Tuesday, April 21, 2020 at 4:28:41 AM UTC-6, Markus Holtermann wrote: > > I vote in favor of Claude becoming a MERGER. > > Cheers, > > Markus > > On Thu, Apr 16, 2020, at 10:31 PM, charettes wrote: > &

Re: Remove automatic date-naming of migrations (00XX_auto_YYYMMDD)

ly matters, and while the date is sometimes useful for people to resolve merge conflicts, I don't think it's better than more informative autogenerated names, so I'm happy to go with the change. (60 is a bit long though, maybe we can bump it down to something a bit shorter?) Andrew

Re: [FEATURE] Allow squashmigrations to squash the whole project

quash down to just a couple of migrations each app, it would be nice to have that be a shortcut. Andrew On Wed, Apr 22, 2020 at 10:35 AM Javier Buzzi wrote: > This comes from a place of headaches: we're a large team, and our sprint > are a month long, in that month we generate a l

Re: What's wrong with the jenkins testrun failing on ASGI (I think?)

Yup, I'm seeing if we can get asgiref fixed today, otherwise I'll revert the change that broke Django and issue 3.2.9. Andrew On Tue, Jun 16, 2020, at 2:48 AM, Florian Apolloner wrote: > Ok, so rebasing PRs to current master will fix this (leaving this here as > note for oth

<    1   2   3   4   5   6   7   >