#django

Why do you need to bypass code when running a migration? Just interested.

(Oh, the queries in AppConfig.ready() thing from above)

I'd consider making those lazily evaluated - although you may have a reasonable justification for why they need to happen on system startup.

+1

hmm where in the docs does it describe what has a _set? and how to access that? I always forget that

damnit, my keyboard. where in docs does it describes what a _set is*

sphrak_: It's probably under ForeignKey definitions: basically it's the implicit reverse relation.

I generally (overwhelmingly, actually) explicitly define the reverse relation name.

schinckel: ah okey, but is related_name a field name?

derp

sphrak_: It's a field kwarg

if you use the default auth template names you'll override the admin ones

someone should fix that ...

https://docs.djangoproject.com/en/1.11/topics/a... in particular

schinckel: ah yes sorry, but its something I define on a field then..

Yeah.

[redacted]

sphrak_: https://docs.djangoproject.com/en/1.11/ref/mode...

foo: Yeah, quite extensively with the WizardView

foo: ... but I haven't created a custom storage

schinckel: thank you, will read :-)

[redacted]

[redacted]

[redacted]

[redacted]

[redacted]

Not sure.

[redacted]

schinckel: https://dpaste.de/kPfh do I define related_name correct?

did*

or should it be defined in Days model?

nvm, I wasnt even looking for that, I was looking for self.which_days.all()

is there a way in Django 1.11 to take advantage of PostgreSQL's upsert functionality without dropping down to raw SQL?

was hoping to do something like create_or_update(), but atomic without a unique index

isn't it already wrapped in a transaction?

and what do you mean "without an unique index"?

think of the case of "create or update". If done w/ multiple SQL statements, you might do a SELECT, followed by an INSERT or UPDATE depending on the SELECT result. Wrapping those queries in a transaction does nothing to prevent a concurrent thread from doing an INSERT between your own SELECT and INSERT, unless the PG concurrency level is configured to be very high such as "serializable" described in https://www.postgresql.org/docs/9

.6/static/transaction-iso.html

a unique index in the DB can prevent multiple rows w/ the same unique value set, thus prevent duplicate rows from being created. The first succeeds, the 2nd ones throws an exception because of a unique constrain violation

I thought all write operations were FIFO

IE - no parallel writes

schinckel is the man to ask for this

it depends on the DB and the configuration, but sequential writes across all connections would be rather slow. It would basically be a global write lock ala old MongoDB

hrmm

Melamo: I've got a nice little upsert-alike.

The actual write may be deferred, but the transaction log should have the data in it regardless?

(Actually, bulk_update, but you can manage to do it as bulk_update + bulk_create, in a single @transaction.atomic)

(The initial reference is at http://schinckel.net/2017/06/30/django-bulk_upd..., but I need to post and update, that just uses UPDATE)

Oh wait, the last bit already has that.

hahaha

Maybe I'll edit the post to remove the whole temporary table thing.

schinckel: Awesome! Taking a look now

(You'll still need to have database constraints to prevent the issue you described, unless you are running at SERIALIZABLE or above)

But I use this with exclusion constraints quite a lot (as long as they are deferrable)

Ah I think we might be talking about doing different things. I'm just wanting to make use of the ON CONFLICT of INSERT

Oh, my solution is if you aren't yet on a new enough postgres to do that.

gotcha

yeah in the past I've just used a unique constraint index, but for once I'm using a new and shiny DB install :)

Don't you still need to have the unique constraint, but just tell it to on-conflict <constraint> do instead...?

I'm not sure how postgres native upsert is going to work in django just yet.

schinckel: hmm I think you are right about the index still being needed

why are people working on this fine public holiday

shangxiao: Because our public holiday is on Monday.

hrhr

schinckel: that was more of a lame way to envoke jealousy - i didn't realised adelaidians had a public holiday too

i wonder if sydneysiders have one

NSW, ACT, SA have Labour Day; QLD has Queen's Birthday.

ACT Had Family & Community day on Monday past, WA had Queen's Birthday that day too.

vic has a labour day

that's early in the year

vic has a queen's birthday too

We had Adelaide Cup day on that day.

NT have a public holiday called "Picnic Day"

sounds like a good excuse for a holiday

And Tasmania has Recreation Day.

Which I assume means "Recreational Drugs Day"

[redacted]

foo: ordered dicts have the same interface as a regular dict

it's a bit unclear what you're asking

[redacted]

[redacted]

[redacted]

[redacted]

[redacted]

foo: it sounds like it's self.forms['order_step1']

[redacted]

[redacted]