A postgresql datalayer for the Ash Framework
Find a file
2020-06-02 22:48:12 -04:00
.github chore: fix credo warnings 2020-06-02 22:48:12 -04:00
config chore: release version v0.1.2 2020-06-01 01:36:43 -04:00
lib chore: fix credo warnings 2020-06-02 22:48:12 -04:00
test WIP 2020-01-17 12:24:07 -05:00
.check.exs chore: fix credo warnings 2020-06-02 22:48:12 -04:00
.credo.exs chore: fix credo warnings 2020-06-02 22:48:12 -04:00
.formatter.exs WIP 2020-04-03 23:42:15 -04:00
.gitignore WIP 2019-12-04 09:58:20 -05:00
CHANGELOG.md chore: add git_ops 2020-06-01 01:37:00 -04:00
LICENSE WIP 2019-12-04 10:13:24 -05:00
mix.exs chore: fix credo warnings 2020-06-02 22:48:12 -04:00
mix.lock chore: fix credo warnings 2020-06-02 22:48:12 -04:00
README.md chore: fix credo warnings 2020-06-02 22:48:12 -04:00

AshPostgres

Elixir CI License: MIT Coverage Status Hex version badge

TODO

Configuration

  • Need to figure out how to only fetch config one time in the configuration of the repo. Right now, we are calling the installed_extensions() function in both supervisor and runtime but that could mean checking the system environment variables every time (is that bad?)
  • Figure out heuristics for when to left join/right join (alternatively, make it configurable via the query language) For instance, if a relationship has a non-nil predicate applied to it in all ors or a single and then we should be able to inner join. I have learned from experience that no single approach here will be a one-size-fits-all. We need to either use complexity metrics, hints from the interface, or some other heuristic to do our best to make queries perform well. For now, I'm just choosing the most naive approach possible: left join to relationships that appear in or conditions, inner join to conditions that are constant the query (dont do this yet, but it will be a good optimization) Realistically, in my experience, joins don't actually scale very well, especially when calculated attributes are added.