Underlying DB model for what is now most commonly referred to as a 'Question' in most user-facing situations. Card
is a historical name, but is the same thing; both terms are used interchangeably in the backend codebase.

Collections are used to organize Cards, Dashboards, and Pulses; as of v0.30, they are the primary way we determine
permissions for these objects.

TODO - I think this namespace is too big now! Maybe move the graph stuff into somewhere like
`metabase.models.collection.graph`

Dependencies are used to keep track of objects that depend on other objects, and acts as a sort of m2m FK table. For
example, a Card might use a Segment; a Dependency object will be used to track this dependency so appropriate
actions can take place or be prevented when something changes.

Dimensions are used to define remappings for Fields handled automatically when those Fields are encountered by the
Query Processor. For a more detailed explanation, refer to the documentation in
`metabase.query-processor.middleware.add-dimension-projections`.

Logic related to humanization of table names and other identifiers, e.g. taking an identifier like `my_table` and
returning a human-friendly one like `My Table`.

There are currently three implementations of humanization logic; `:advanced`, cost-based logic is the default; which
implementation is used is determined by the Setting `humanization-strategy`; `:simple`, which merely replaces
underscores and dashes with spaces, and `:none`, which predictibly is merely an identity function that does nothing
to the results.

The actual algorithm for advanced humanization is in `metabase.util.infer-spaces`. (NOTE: some of the logic is here,
such as the `captialize-word` function; maybe we should move that so all the logic is in one place?)

A Metric is a saved MBQL 'macro' expanding to a combination of `:aggregation` and/or `:filter` clauses.
It is passed in as an `:aggregation` clause but is replaced by the `expand-macros` middleware with the appropriate
clauses.

Intersection table for `Metric` and `Field`; this is used to keep track of the top 0-3 important fields for a metric as shown in the Getting Started guide.

Utility functions for dealing with parameters for Dashboards and Cards.

A `PermissionsGroup` is a group (or role) that can be assigned certain permissions. Users can be members of one or
more of these groups.

A few 'magic' groups exist: `all-users`, which predicably contains All Users; `admin`, which contains all
superusers, and `metabot`, which is used to set permissions for the MetaBot. These groups are 'magic' in the sense
that you cannot add users to them yourself, nor can you delete them; they are created automatically. You can,
however, set permissions for them. 

Notifcations are ways to deliver the results of Questions to users without going through the normal Metabase UI. At
the time of this writing, there are two delivery mechanisms for Notifications -- email and Slack notifications;
these destinations are known as 'Channels'. Notifications themselves are futher divied into two categories --
'Pulses', which are sent at specified intervals, and 'Alerts', which are sent when certain conditions are met (such
as a query returning results).

Because 'Pulses' were originally the only type of Notification, this name is still used for the model itself, and in
some of the functions below. To keep things clear try to make sure you use the term 'Notification' for things that
work with either type.

One more thing to keep in mind: this code is pretty old and doesn't follow the code patterns used in the other
Metabase models. There is a plethora of CRUD functions for working with Pulses that IMO aren't really needed (e.g.
functions for fetching a specific Pulse). At some point in the future, we can clean this namespace up and bring the
code in line with the rest of the codebase, but for the time being, it probably makes sense to follow the existing
patterns in this namespace rather than further confuse things.

Functions related to the 'Query' model, which records stuff such as average query execution time.

A model used to cache query results in the database.

QueryExecution is a log of very time a query is executed, and other information such as the User who executed it, run
time, context it was executed in, etc.

Functions used to calculate the permissions needed to run a query based on old-style DATA ACCESS PERMISSIONS. The
only thing that is subject to these sorts of checks are *ad-hoc* queries, i.e. queries that have not yet been saved
as a Card. Saved Cards are subject to the permissions of the Collection to which they belong.

A Segment is a saved MBQL 'macro', expanding to a `:filter` subclause. It is passed in as a `:filter` subclause but is
replaced by the `expand-macros` middleware with the appropriate clauses.

(require '[metabase.models.setting :as setting])

(setting/get :mandrill-api-key)           ; only returns values set explicitly from SuperAdmin
(mandrill-api-key)                        ; returns value set in SuperAdmin, OR value of corresponding env var,
                                          ; OR the default value, if any (in that order)

(setting/set! :mandrill-api-key "NEW_KEY")
(mandrill-api-key "NEW_KEY")

(setting/set! :mandrill-api-key nil)
(mandrill-api-key nil)

Settings are a fast and simple way to create a setting that can be set from the admin page. They are saved to the
Database, but intelligently cached internally for super-fast lookups.

Define a new Setting with `defsetting` (optionally supplying a default value, type, or custom getters & setters):

   (defsetting mandrill-api-key "API key for Mandrill")

The setting and docstr will then be auto-magically accessible from the admin page.

You can also set the value via the corresponding env var, which looks like `MB_MANDRILL_API_KEY`, where the name of
the setting is converted to uppercase and dashes to underscores.

The var created with `defsetting` can be used as a getter/setter, or you can use `get` and `set!`:

    (require '[metabase.models.setting :as setting])

    (setting/get :mandrill-api-key)           ; only returns values set explicitly from SuperAdmin
    (mandrill-api-key)                        ; returns value set in SuperAdmin, OR value of corresponding env var,
                                              ; OR the default value, if any (in that order)

    (setting/set! :mandrill-api-key "NEW_KEY")
    (mandrill-api-key "NEW_KEY")

    (setting/set! :mandrill-api-key nil)
    (mandrill-api-key nil)

Get a map of all Settings:

   (setting/all)

Settings cache. Cache is a 1:1 mapping of what's in the DB. Cached lookup time is ~60µs, compared to ~1800µs for DB
lookup.

The ViewLog is used to log an event where a given User views a given object such as a Table or Card (Question).