fix(modelling): Try any posthog table from modelling

[Gilbert09]

Problem

• We can run modelling on queries that use the numbers table function

Changes

• Change how we read posthog tables - moved this logic to be last after looking up saved views/warehouse tables as these tables will return from the same function too

Does this work well for both Cloud and self-hosted?

Yes

How did you test this code?

Added a test

[greptile-apps]

PR Summary

This PR adds support for the numbers table function in PostHog's modeling system by changing how table validation works in the modeling framework.

• Modified get_or_create_query_parent_paths() to check saved queries and warehouse tables first before falling back to PostHog tables
• Changed PostHog table validation to use get_table() with exception handling instead of checking against a static list
• Added a test case in test_modeling.py that verifies numbers(10) is correctly identified as a parent table
• Added QueryError import from posthog.hogql.errors to properly handle table resolution exceptions
• Improved robustness by using the actual table resolution mechanism rather than static list checks

_{2 file(s) reviewed, no comment(s)
Edit PR Review Bot Settings | Greptile}

[tomasfarias]

I think this may conflict with my earlier fix. But, by the way, this method will not fail on numbers as it just extracts the names, doesn't actually check that the table exists (see my earlier fix which includes numbers).

[Gilbert09]

Yeep - just resolved these

[tomasfarias]

Cool, but fyi, this test is not actually testing what this PR is fixing (as you can see by existing tests already covering numbers)

[Gilbert09]

Yeah i don't really understand how your test passed without my change 🤔

[tomasfarias]

Because the method in the test (get_parents_from_model_query) is not checking that the tables are valid names, just resolving the names.

[Gilbert09]

Ah, I was looking at the wrong method 🤦 I'll fix

[tomasfarias]

Looks good once conflicts are fixed