#django

Were select_related and prefetch_related not useful?

But yeah, being able to populate related models with raw() is a longtime wishlist item of mine.

ihor: You can use a View as the source of models, and then do select_related etc.

Right, but select_related will still join to the other model.

Well, you get a new model, which you can still access using related_nam

That's the piece I'd love to have, is something like select_related(trust_me_i_already_queried_those_fields=True)

mattmcc: it is usefull, but join all records in related table and then apply filters on joined table.

mattmcc: +1

ihor: You might want Prefetch objects; sometimes that can do what you might need there.

ihor: You can filter prefetch_related with a queryset of the related model to get around that.

No guarantees though ;)

No, prefetch_related is not option

schinckel: I can not get what about you talk. Can you please post link on example or documentation?

> You can use a View as the source of models, and then do select_related etc.

this

Oh, right, sorry.

Also, https://gist.github.com/mattmcc/5250561

This pattern works if you have an SQL View that does the query you want (and then you may still filter it, as you see fit).

schinckel: nice! It is looks nice

You can even use that sort of stuff with recursive CTEs.

I need to check how indexes works with views and how to update views for big table

It uses the indexes on the original tables: views are calculated live.

Views are essentially stored queries. Materialized views, though, can have their own.

Yeah, that.

Which has pros & cons. Updates to large materialized views may be more expensive than if you'd used a plain view and updated its constituent tables for example.

We use a materialized view for products so that (among other reasons) all the FTS related indexing that pulls from a dozen tables happens in one place.

> building materialized view with FTS

Does it have any cons over separated FTS solution?

sorry advantages

It just depends on your needs. Our FTS needs are met quite adequately by PG's own FTS support, so we use that rather than maintain, say, an Elasticsearch stack.

my application has organizations and members, and i'm writing an API in which the organization payload contains a list of it's members, and the members endpoint contains a reference to the organization (that links a User with the Organization)

i'm wondering if that's bad design, it has some code smell because the serializers i am using are referencing each other

the MemberSerializer is in the same file as the OrganizationSerializer and they both need to reference each other

i guess my question is, should i be remodelling my payloads and the way the front end consumes this data to not do this? or is there something i'm missing

limbera you're alive

This is a great thing

hey mate

hah yes i am

limbera - its not bad design, especially if you are implementing a strict HATEOAS pattern

But typically you'll have "reduced" serialisers for the nested resources

i am doing so

and i am doing that too

how are you mate?

Great!

You?

PM

how do i handle the OrgSerializer trying to serialize the MemberSerializer

limbera: !

what is meaning of this https://bpaste.net/show/9283721d312a

limbera - do you want it do?

dont know how to fix this

asked in python , later realized not a right room so asking here

limbera - you can always set it to `read_only=True`

valhalla_22: what did you do to elicit that error?

earlier i thought it was time stamp format error due to UTC or something else.

did you run a command?

valhalla_22: are you going to provide the full tracback?

python - m unittest -v test

sure FunkyBob i will

valhalla_22: oh... why not "manage.py test" ?

like you saw in the tutorial? and in the docs?

specifically, that error is complaining you haven't set the DJANGO_SETTINGS_MODULE env var... which manage.py does for you

yes now i get it , i have two settings defined in django

python manage.py test --settings=.....

manage.py will only set it if it's not set... so you can also do DJANGO_SETTINGS_MODULE=.... ./manage.py test

settings.py and settings.test.py and settigns.production.py

not python friendly names

also, I'll shamelessly self-promot and suggest you look at django-classy-settings :)

it can make that sort of thing easier to maintain

yes old school better to understand.

indeed.

you might want to opt for _ not . in the filenames

anyway... time to leave work

sorry got disconnected