[Feature] Add unix-style fqn wildcard selector method

[z3z1ma]

resolves #6598

Description

Adds a new selector method plus tests. This method is called wildcard. It uses fnmatch from the python stdlib.
Reference here

We look at the fqn as a string:

project.resource.some.dir.my_model
project.resource.some.dir.schema_file.dbt_utils_expression_is_true_my_model_column_a

And simply use fnmatch to determine if it is selected:

Here's a convoluted example just to show how flexible and robust you can imagine this being:

dbt test -s 'wildcard:project.*.*.dir.schema_file.*_column_a

Also you can see the tests as a reference for playing with it if you want to continue imagining what it opens up.

Checklist

• I have read the contributing guide and understand what's expected of me
• I have signed the CLA
• I have run this code in development and it appears to resolve the stated issue
• This PR includes tests, or tests are not required/relevant for this PR
• I have opened an issue to add/update docs, or docs changes are not required/relevant for this PR
• I have run changie new to create a changelog entry

[aranke]

LGTM, thank you!

[ChenyuLInx]

Hey @z3z1ma Thanks for this amazing PR that provide a powerful feature! Great work think through which selector methods should support wildcards!

I want to make sure I understand the exact function you are adding here.
For existing selector, the following now support wildcard( the rest are more status based so they don't need to support wildcard match)

• FQN
• Tag
• Source
• Exposure
• Metric
• File
• Package
• TestName

And added a new one Wildcard.

After playing with it a bit I have some question/ask

1. FQN selector support everything Wildcard selector support, plus special logic to the following possible. Is that correct? Is they anything that the wildcard support that the new FQN doesn't supports? If not should we consider just leave the new FQN, or remove wildcard match from FQN and add the new wildcard selector method, whichever feels more consistent with other selector methods.

   dbt-core/test/unit/test_graph_selector_methods.py

   Lines 659 to 660 in 60fde4d

   	assert search_manifest_using_method(
   	manifest, method, 'pkg.unions') == {'union_model', 'mynamespace.union_model'}

2. Do you mind add some new test to the tests for those selectors that supports wildcard match? For example, for test_select_tag maybe we can add something like

   assert search_manifest_using_method(manifest, method, 'uses_eph*') == {
           'view_model', 'table_model'}

3. Only because this change is super powerful, I would like us to think a bit more about is there any concern of the this fnmatch would cause the

   1. additional things got selected for user's existing selection command?(@z3z1ma @aranke you two probably know the use case better than I do)
   2. performance issue of selector on large projects (@jtcohen6 should we test this on some large size testing project before merging?) (EDIT: Thinking again this shouldn't have performance issue on existing selection. Might be slow for new selection that uses wildcard.)

[z3z1ma]

FQN selector support everything Wildcard selector support, plus special logic to the following possible. Is that correct? Is they anything that the wildcard support that the new FQN doesn't supports? If not should we consider just leave the new FQN, or remove wildcard match from FQN and add the new wildcard selector method, whichever feels more consistent with other selector methods.

The Wildcard selector is an artifact from the initial spike in which I had not planned on updating the other selectors.
After some iteration I found I could implement the functionality without any breaking change. So consider that the Wildcard selector will be dropped since the functionality is native to FQN.

We should definitely keep the wildcard matching capabilities on FQN because, as the default selector, it is significantly more accessible to users. Furthermore, existing use of the * character is functionally unchanged by this update. This means its a net new feature that does not change users who opted to use the old FQN "selector glob". Telling users they can run models using wildcard goodies out of the box without explicitly specifying wildcard: is big.

Command	Old Outcome	New Outcome
dbt run -s something.*	Select all nodes from package something	Select all nodes from package something
dbt run -s something.idk_*	Select all nodes whose fqn starts with [something, idk*, ...] (weird right)	Select all nodes from package something whose next fqn segment starts with idk_

Unless a user has * or ? or [] in their filenames which should be impossible or just an ill-advised move, we should be shored against any possibility (that I can conjure) of this not being backwards compatible. If anything, this might be more intuitive because I believe we have all used globs at one point thinking they would work in the middle of an fqn segment.

Can elucidate more tomorrow (new comment or will edit this one), but do expect a commit that drops Wildcard and updates to the tests @ChenyuLInx

[ChenyuLInx]

@z3z1ma Thanks for the fast response!! This makes sense to me!! I was asking the third question only out of cautious not that I think the answer would be no.
Looking forward to the your new commit!

[z3z1ma]

@ChenyuLInx @aranke

Mentioned updates are complete.

• More tests for other methods with extended wildcard enabled
• Drop of independent Wildcard selector from initial spike since it is baked into FQN

[ChenyuLInx]

Looks great! Thanks @z3z1ma !