Pattern Cards+implementation+older notes

Here's the general process:

1. Get all the patterns to which the card conforms in order of pattern precedence.  There are lots of possibilities for implementing and optimizing this step, so we should spend some time addressing trade-offs.  One idea would involve storing a representation of a pattern's search that lets us do reverse searches from cards.  Another would be an algorithm that lets us traverse all patterns quickly, eliminating most of them using things like "type", and running the remaining queries to confirm conformity.  Most any solution will involve caching a card's pattern list so that this doesn't happen often, and this cache will need to get cleared whenever applicable patterns are created, destroyed, or reordered (but *not* when patterns are edited.  and no settings changes should have any impact at all).  Another possibility, probably unwieldy (esp on big wagns), would be an xref table containing all patterns and all the cards that match them.
2. Going from strongest to weakest pattern, look for the given setting card for each pattern.  Stop when you get one!

This process might be triggered by something like @card.setting(:form).

NOTE: while the two steps above are a good short representation of the process, it's possible we may want a hybrid approach.  When we're looking for a given setting, we might only need the strongest pattern, in which case loading the entire pattern list could be overkill.  In that case, we might decide to construct only as much of the pattern list at any given time as we need to find a setting.  At first glance, that looks unlikely to be worth the effort, especially if a card gets lots of viewings between pattern-precedence-altering events.

A second, important, use case involves performing a WQL search and having it further limited by a certain pattern.  The only instance of this we've considered so far is returning only cards that the user has permission to read, which means relying on the read permission setting (see Pattern Cards+permissions ).  But we might imagine it coming up again for bulk updates, bulk deletes, etc.

One route would be to cache the read permission as we have done, but this is complicated by the new permissions design in that a given card might have multiple parties.  Another possibility is that we cache the id of the +*read setting card that governs each card, and for each user we cache ids for all the +*read cards that grant the user permission.  Oooh.  That's kind of cool. 

The trick there is that we'd have to be able to update +*read id caches when new settings emerged or pattern precedence shifted.  But if we want (a) to be caching permissions and (b) to have a means of updating lots of permissions at once, this is probably a problem we're going to have to face in one form or another.

(Needs further discussion).