API Reference sorcery v0.4.4
Modules
To get started with Sorcery, let's use the generator
Functions for combining Sorcery and GenServer clients. Put these in your init function to create portals and receive updates.
This is a garbage collector, of sorts.
Functions for combining Sorcery and LiveViews
This is the interface for creating changes in Sorcery. Mutations have some similarities to Ecto Changesets in the sense that we are building a struct that defines all the changes without actually applying them. But there are many differences, as you will soon see.
A PortalServer is a special type of GenServer. Portals are created between different PortalServers, always in a hierarchical parent <--> child relationship.
This exists to resolve a lot of confusion caused by generically using the word 'state' to refer to either the data inside the :sorcery key, or the data including :sorcery. For example a LiveView would have socket.assigns.sorcery So does state refer to socket.assigns? Or socket.assigns.sorcery? In theory, Sorcery should never need to access the outer map, aside from maybe the helpers at most.
A Portal represents an ongoing SrcQL Query. Rather than grabbing data and ending, it continues watching for changes to the results set.
A query module defines, in plain elixir data structures, the kind of data we want to watch for.
This is the return type of any forward query, and any generated data.
In sorcery, you must define your entity types as 'Schemas'
WIP currently it is not possible to add your own custom field types. But in the future it should be possible since they all follow this behaviour
A store adapter is a module that allows a PortalServer to access a data store by taking SrcQL, and converting it into something compatible with the specific store.
This adapter requires the repo module to be passed in as args.
Since we are translating SrcQL into SQL, there are some oddities. One is how we handle completely unrelated lvars that are not joined. So in this adapter we call cluster a group of where clauses and joins together, and call it a thread. We must call Repo.all(thread) seperately with each thread.