This raises the question to me: do we want to call each extension's filter, or only if any of their filter fields are set?

I feel like we can call it always. The extension's apply_filter should (need to?) have logic to determine if they are being called or not.

This way we can also inject some logic even if the extension does not have any filter present

base.apply_filters(self, stmt)

Good enough for the PoC, but something to figure out how we'll clean it up for the actual implementation. StrawberryFilter defines apply_filter as an instance method. You typically call them on an instance. That is what you would expect. But you now forcefully call them on the class and have to pass in the instance.

I think that one solution would be the separation between data and logic that I drafted, but that had complications of its own. Another could perhaps be to use a class method instead.

Great for the draft. For the eventual interface it's still unclear to me what we want this to be exactly. Mostly does it modify the select or does it simply return a join directive.

Like a cte that we then join to filter on?
I feel like modifying the select might be clearer. wdyt?

mypy still hates this

Is casting this as typing.Any the best solution?

Maybe ResourceFilterABC is better

I wonder if the order ever matters here (apart from that it should be deterministic). I think not? i.e. we could safely call this on the lsm filters first and only then on the core ones?

I believe that the order does not matter.

Do we really need to be this dynamic? I think it could be a bit more robust / consistent if we can make sure that we initialize once to start with, and reject additional filters afterwards. Wdyt?

If we move this into graphql.schema (and perhaps make a singleton by operating at class level rather than instance level)?, can we get rid of the whole passing around of the slice and engine that's going on there? Or am I missing something?

Why do we need purged at this level?

Do we still need is_orphan at this level, considering what we discussed earlier this week? i.e. lsm filters are always about the latest intent (we may still need to figure out how to enforce that, but that's a different matter).

I put is_orphan and purged at this level to make mypy happy because they are used in the resources query.

I see.

1. I worry that is_orphan might cause us trouble in the next stage, but let's see about that when we get there. For now it's fine here.
2. I'm pretty sure that we'll have to update the condition that we use to determine whether or not we can use the simplified count (a complication I hadn't thought of until just now). Once we have addressed that, if we're lucky purged will have disappeared from the resources query.

Apparently this Self isn't really safe. Took it to Slack.

With this move we'll have to make sure to not reintroduce the bug where we omit the environment filter. But I guess the test you expanded will protect us from that.

I still need to give this some more thought to see if we can do anything about the clunkiness here. No immediate ideas yet.

I think this can be improved to better address the caller. I.e. "the composed ResourceFilter has yet to be generated" is an implementation detail. The corresponding client contract is that it must be called before this slice starts, so during the prestart stage, or the start stage of a slice that registers this one as a dependency.

Why pass this through the context? It requires quite some wiring, and I don't think it really offers us anything?

I think I see. You use the context so you can access it in the resources method. But wouldn't it be a lot simpler to simply store it as a class var on the Query object? Or even just use the value from the closure, though I think I prefer to make it explicit on Query.

I tried setting it as a variable of Query but got some errors, needs to be a GraphQL valid type and I got some conflicts there. And I feel like context is a good "container" for all the small things that we get from the slice to the schema.

Bit of a nitpick, and I don't care too strongly, but I think it could turn out slightly cleaner if we move this responsibility to get_schema. i.e. the slice knows about extensions, the schema knows about core and how to extend it with extensions. Apart from the slightly debatable semantical improvement, I think it offers the following benefits:

• We get rid of the back-and-forth where we import a filter from the schema here, to pass it back down to the schema. This flow feels a bit weird to me.
• We make the typing.Annotated a bit more safe, because if get_schema is the one that injects the core filter, than we actually know that the generated type will be an instance of it. Otherwise we introduce more coupling, because the typing.Annotated depends on the assumption that the slice injects the core resource filter.

Not sure what you mean by this. So we wouldn't have all_filters as a concept on the slice? Or do you mean that GraphQLSlice does not register CoreResourceFilter but keeps all the other filters, and then we just append CoreResourceFilter on get_schema?

Pretty much. Well, I think prepend would be safest, but that's beside the point.

Why use getattr()? To be extra robust? It normally shouldn't ever be absent, should it?

I'm not sure how would the alternative look like. Or do you mean the default to strawberry.UNSET?

I was somewhat mistaken here, sorry. What I meant indeed boils down to the default.

I remember I ran into some issues without the default. But that may have been from a previous iteration where we where converting to dict.

The tests seem to pass without the default, I'll remove it so we can more easily diagnose if something goes wrong

Not necessarily in scope for this PR, but why do we check for UNSET actually? It's not of type StrawberryFilter, is it?

I think this is just an iteration artifact. I check for UNSET before I call this when applicable

Interesting. I believe I proposed something like this at some point and we didn't go this way. Why did you change it? I assume it has to do with the fact that we need both input and output? How / when do they differ in their fields?

EDIT: Ah, I guess "meta" filters like includeOwned... We could probably also use annotations on the fields to determine whether they're in/out/both. But let's go with this approach for now and see how it ends up. If it looks clean, this is probably the simplest. If it turns out to be too repititive / coupled, perhaps we can reconsider.

What's this? The docstring doesn't make it clear to me and I don't see it being used anywhere.

I thought we were moving away from this context object?

(Also related to the comment above) I don't think we can/should. The way we fetch lsm related information will be through custom resolvers (like the purged attribute). I want the extensions to inject stuff that they require here to help in the logic of the custom resolvers. This is an example that Claude made:

```python
@dataclasses.dataclass
class _LsmResourceData:
    service_entity: str
    service_instance_id: uuid.UUID
    lifecycle_state: str

Shared DataLoader helper:

async def _load_lsm_data(root: Any, info: Info) -> Optional[_LsmResourceData]:
    make_loader = info.context.get("lsm_resource_info_loader_factory")
    if make_loader is None:
        return None
    cache_key = f"_lsm_info_loader_{root.environment}"
    loader = info.context.get(cache_key)
    if loader is None:
        loader = make_loader(root.environment)
        info.context[cache_key] = loader
    return await loader.load(root.resource_id)

Three individual field resolvers (each call _load_lsm_data, extract one attribute):

async def _get_lsm_service_entity(root, info) -> Optional[str]: ...
async def _get_lsm_service_instance_id(root, info) -> Optional[uuid.UUID]: ...
async def _get_lsm_lifecycle_state(root, info) -> Optional[str]: ...

Mixin class:

class _LsmResourceMixin:
    lsm_service_entity:      Optional[str]       = strawberry.field(resolver=..., description="...")
    lsm_service_instance_id: Optional[uuid.UUID] = strawberry.field(resolver=..., description="...")
    lsm_lifecycle_state:     Optional[str]       = strawberry.field(resolver=..., description="...")

Performance: No impact from having 3 resolvers instead of 1. The DataLoader batches
all loader.load(resource_id) calls within the same async tick into a single SQL query,
and caches results by key — subsequent load() calls for the same key return the cached
_LsmResourceData without a database round-trip. Result: still one SQL query per
environment per page regardless of which or how many inline LSM fields are requested.

LsmResourceFilterFields

@strawberry.input
class LsmResourceFilterFields:
    service_entity:           Optional[StrFilter]       = strawberry.UNSET
    service_instance:         Optional[list[uuid.UUID]] = strawberry.UNSET
    lifecycle_state:          Optional[StrFilter]       = strawberry.UNSET
    service_instance_version: Optional[int]             = strawberry.UNSET
    include_owned:            Optional[bool]            = strawberry.UNSET

DataLoader for inline LSM fields

get_context_loaders() returns {"lsm_resource_info_loader_factory": make_loader} where
make_loader is a per-environment factory creating a DataLoader on first use. One
DataLoader instance per environment per request; all resources on the same page share one
batch SQL query.

The batch query fetches all three values in one shot (selecting more columns than a caller
might need is negligible cost compared to an extra round-trip):

SELECT
    elem                             AS resource_id,
    lt.resource_id_value             AS instance_id,
    lt.attributes->>'service_entity' AS service_entity,
    si.state                         AS lifecycle_state
FROM resource lt
JOIN resource_set_configuration_model rscm ON ...
JOIN (SELECT MAX(version) AS version FROM configurationmodel
      WHERE environment = $1 AND released = TRUE) lv ON rscm.model = lv.version
LEFT JOIN lsm_serviceinstance si
    ON si.id::text = lt.resource_id_value AND si.environment = lt.environment
CROSS JOIN LATERAL jsonb_array_elements_text(lt.attributes->'resources') elem
WHERE lt.environment   = $1
  AND lt.resource_type = 'lsm::LifecycleTransfer'
  AND lt.attributes->>'resources' != '<<undefined>>'
  AND elem = ANY($2)

Wouldn't it be simpler to move this part to the caller so that we don't have to return a tuple? Optionally make it a second helper method tuple[type[ResourceFilterABC], ...] -> type if you don't want the complexity in get_schema()?

This level of meta-programming scares me a bit with respect to stability. I need to think if I see a better way.

Yeah, I agree that this is one of the parts that scares me the most, Claude wrote it, for better or worse

If we use mapper.type(models.Resource), won't it prevent the query from returning anything other than a models.Resource object?

Open question. I don't feel like I understand the framework sufficiently to give an answer myself.

No. It creates a strawberry type based on the attributes of models.Resource but it is not indeed the same object since we can add fields to it (we already do the same with the purged attribute for example)

Nice. I don't recall if I've already reviewed since this change, but I prefer it a lot over the previous approach.