Explain the internal working of Micronaut Data repository method generation?

Micronaut Data turns a repository interface into a concrete implementation entirely at compile time, without generating SQL strings at runtime or relying on a persistence framework's dynamic proxy.

For a derived query method like findByStatusAndCustomerId(String status, Long customerId), the processor tokenizes the method name into predicate parts, matches each token against a property on the entity validated using the entity's compile-time introspection metadata, and builds an internal query model describing the WHERE clause and parameter bindings.

That model is then rendered into dialect-specific SQL, since Postgres, MySQL, and others each have slightly different syntax, and a real implementation class is generated that executes this fixed SQL via JDBC, or the JPA EntityManager for the JPA flavor, and maps result rows back onto the entity using generated introspection, not reflection.

Because the query and its parameter bindings are fixed at compile time, there's no runtime query-string parsing per call, and a method name that doesn't match any entity property fails the build immediately rather than throwing an exception in production.