So, plump-pg is super clever about pulling in child relationships for queries. The problem behind this is two-fold:
- it is sometimes difficult to infer which version of the query you want (do you just want attributes, or do you want prejoined children? if so, which children?)
- writing
sql blocks into model definitions is basically building a DSL.
My suggestion is that this feature be deprecated and removed. Since I'm probably still the only person really using this library, I'll be doing that in the next version. Instead, the database should use views to get this data, and we'll support having different table / view names for different query formats.
Basically: instead of allowing the pgstore code to do a best-guess as to the kind of join query you want to run, you should create some views that have the appropriate stuff in them. Then you can define different views in the ModelSchema block that says, "if you're pulling the whole shebang, use documents_full, otherwise use documents" or whatever.
So, plump-pg is super clever about pulling in child relationships for queries. The problem behind this is two-fold:
sqlblocks into model definitions is basically building a DSL.My suggestion is that this feature be deprecated and removed. Since I'm probably still the only person really using this library, I'll be doing that in the next version. Instead, the database should use views to get this data, and we'll support having different table / view names for different query formats.
Basically: instead of allowing the pgstore code to do a best-guess as to the kind of join query you want to run, you should create some views that have the appropriate stuff in them. Then you can define different views in the ModelSchema block that says, "if you're pulling the whole shebang, use documents_full, otherwise use documents" or whatever.