- whole path is saved to array, ending in it's own key.
- can lookup parent/children very easily with scopes
- adding/querying is easy & fast, but rearrangment gets more complicated
- belong to Brandfolder
- soft deleted (all children soft deleted too)
- api/v4/(brandfolders || collections)/:key/labels
- #index (see permissions section below)
- #create
- api/v4/labels_controller/:key
- #update (except for path)
- #move (parent_key) handles all children
- #destroy
- scopes
- child_lookup_for
- parent_lookup_for
- peers_for
- closest_descendants
- with_depth
- ordered_by_depth
- at_depth
- Asset Label joins table
- api/v4/bulk_actions/assets_controller
- #add_to_label
- #remove_from_label
- soft deleted
- v4/bulk_actions/assets/#add_to_label && #remove_from_label
- Brandfolder/Collection Collab+
- v4/resource/:key/labels#index
- Brandfolders
- Collab+ returns all associated labels
- Guest joins AssetLabels & returns ALL PARENTS for those labels
- Collections
- joins AssetLabels & returns all parents
- Brandfolders
- v4/resources/:key/labels#create && api/v4/labels_controller/:key#update && #move && #destroy
- Brandfolder Admin+ (No Collection Admins)
- Id's in path instead of keys (length considerations)
- add/remove in bulk assets controller? brandfolder_key requirement in the bulk assets controller? (Kevin)
- Destroy/Move to async job due to cascade effect 3.5 Transaction blocks (nest_under/move method, BulkAssets#add_to_label)
- Deny move in #update => custom error message (Kevin)
- org_consistency validations... thoughts?
- Label validations (path length limited to depth of 20, name must be present)
- path @> $PATH = where path contains $PATH
- path <@ $PATH = where $PATH is contained by path
- Postgres References: https://www.postgresql.org/docs/9.1/functions-array.html
- Materialized Path: https://leopard.in.ua/2013/07/11/storing-trees-in-rdbms
- Hierarchical Recall with Postgres: http://www.monkeyandcrow.com/blog/hierarchies_with_postgres/