Any interest in update_fields=dict(...)?

I have a use case where I am retroactively adding save(update_fields=...) to an existing code base. Sometimes the code is structured such that 'self' of the model is modified in other helper methods of the model, but not saved immediately. It seems like it would be useful to restructure the

Constraints across foreign keys

Let's say I have: class Restaurant(Model): pass class Table(Model) restaurant = ForeignKey(Restaurant) class Chair(Model) restaurant = ForeignKey(Restaurant) table = ForeignKey(Table) Is there a best practice for ensuring that the chair assigned to a table is always from the same

multidb, don't create one of them during unit tests

I'm using Django's (1.11) typical default db for my regular Django development, but I need to integrate with someone else's bugzilla db server running on mysql somewhere else (no web api available, mysql is the recommendation from them). So I've added a 2nd DB to my DB config pointing to th

Re: multidb, don't create one of them during unit tests

On Tuesday, May 29, 2018 at 12:09:46 PM UTC-7, Rich Rauenzahn wrote: > > > Is this possible? How? > > Ah, found this thread which suggests just using sqlite locally... I'll give it a try: https://groups.google.com/forum/#!topic/django-users/jxkTmibjmX4 -- You received

Fixtures won't load twice in same testcase

I'm having a strange problem. My test environment has been working fine, but I am upgrading my environment's Django revision slowly, which means I also need to move away from django-nose's FastFixtureTestCase. I'm now at Django 1.7. I have a TestCase which is more or less... class Foo(TestC

Re: Fixtures won't load twice in same testcase

I've been tracing into django core code, and it looks to me that I have a case where the fixture has a auth.User(username=rich) with a pk=1 in the fixture. But sometimes as the User fixture with pk=1 is being added (updated?) through Model._save_table(), the same User with pk=5 is already in

Re: Fixtures won't load twice in same testcase

On Thursday, May 5, 2016 at 4:22:11 PM UTC-7, Mike Dewhirst wrote: > > Are you using setUp() and tearDown() as class methods in your test class? > > No, the code was using setUpClass(), which is a classmethod. -- You received this message because you are subscribed to the Google Groups "Djan

Re: Fixtures won't load twice in same testcase

On Friday, May 6, 2016 at 4:11:42 AM UTC-7, Alasdair Nicol wrote: > > >> >> But In this particular run I'm currently tracing, rich is already in the >> db (as the only entry) as pk=5 (via fixture loading process). For one, >> this tells me the sequence generators aren't always resetting betwe

Unexpected poor template performance

I'm working on a project that needs to occasionally render very large tables -- I'm picking hundreds of thousands of cells as a test point for trying out back end implementation scalability. I'm parallelizing some of the rendering through ajax calls that returns large subsets of the rendered c

Paginator UnorderedObjectListWarning on union(all=True) of two sorted queries

I wonder if this is a case you want to catch and *not* warn about. In my case, I'm doing a: haves = MyModel.objects.filter(foreign_relationship=4).order_by('foreign_relationship__value', 'common_key') havenots = MyModel.objects.exclude(id__in=haves).order_by('common_key') query = haves.union(

Extending Form to include 'placeholder' text

Hi, I'd like to make a mixin to set the placeholder text in the widget attrs. Reading this https://code.djangoproject.com/ticket/5793, it seems that extending Meta for custom fields is somewhat discouraged. Would the following be the recommended way to do it? Just adding a class variable to t

Absurdly long queries with Postgres 11 during unit tests

This is heads up in case anyone sees something similar: I have managed to trigger this degenerate query case in two completely different Django 2.2 projects. In production with a normal sized dataset, the query time is fine. But during unit testing with a small subset of the data, the querie

Migrations appear to run twice when running tests

I'm trying to figure out why my migrations appear to run twice when unit testing.I do have multiple dbs with custom routers to route to different databases. I've tried debugging and tracing the routers to see if that's where the issue lies, but I don't know enough about the migration proce

Influencing order of internal migration operations

I've created a CompositeForeignKey constraint derived from Django's new BaseConstraint. It requires that I manually make a unique_together in any of the referenced models views due to the DB internal requirements of composite foreign keys. It mostly works -- except that when the operations are