Module com.darkcollective.relix.processor
Package com.darkcollective.relix.processor.generator

Class GeneratorRegistry

java.lang.Object
com.darkcollective.relix.processor.generator.GeneratorRegistry
All Implemented Interfaces:
GeneratorCatalog
public final class GeneratorRegistry extends Object implements GeneratorCatalog
The catalogue of Generators, indexed by name (case-insensitive) — the built-in ones, plus any a program registers.

Also implements the GeneratorCatalog seam, so the same registry that produces rows at execution supplies generator schemas to semantic analysis — each generator stays defined in one place. The CLI wires this registry into both the analyzer (as a GeneratorCatalog) and the GeneratorDataSourceConnector.

  • Constructor Details

    • GeneratorRegistry

      public GeneratorRegistry()
      A registry of the built-in generators: the finite Range and the unbounded Naturals/Primes.

  • Method Details

    • register

      public void register(Generator generator)
      Adds a generator to this registry, under its own name.

      A generator is a code-backed leaf relation, which is exactly what a program supplying rows of its own has: the registry is the one directory both halves of the pipeline read, so registering here is what makes a name resolvable to a heading during analysis and to rows during execution.

      A name already taken is rejected rather than replaced. The built-ins are a documented language surface, and a session that silently redefined Range would answer a question about the natural numbers with something else.

      Parameters:
      generator - the generator to register; must not be null
      Throws:
      IllegalArgumentException - if a generator of that name is already registered

    • find

      public Optional<Generator> find(String name)
      Parameters:
      name - the generator name (case-insensitive)
      Returns:
      the generator, or empty if none is registered under that name

    • generatorSchema

      public Optional<Schema> generatorSchema(String name, Map<String,String> args)
      Description copied from interface: GeneratorCatalog
      Returns the schema of the named generator for the given arguments, or Optional.empty() if the generator is unknown.
      Specified by:
      generatorSchema in interface GeneratorCatalog
      Parameters:
      name - the generator name (e.g. "Range"); case-insensitive
      args - the raw generator arguments
      Returns:
      the generator's output schema, or empty if unknown

    • generatorCardinality

      public OptionalLong generatorCardinality(String name, Map<String,String> args)
      Description copied from interface: GeneratorCatalog
      The exact cardinality of the named generator for the given arguments, when known — fed to the cost model so a finite generator (e.g. Range) has an exact row count. Returns OptionalLong.empty() for an unknown generator or an unbounded/unknown cardinality; the default is empty.
      Specified by:
      generatorCardinality in interface GeneratorCatalog
      Parameters:
      name - the generator name; case-insensitive
      args - the raw generator arguments
      Returns:
      the exact row count, or empty

    • generatorBoundedness

      public Boundedness generatorBoundedness(String name, Map<String,String> args)
      Description copied from interface: GeneratorCatalog
      Whether the named generator is finite, for the given arguments — the leaf half of relix.relations.boundedness, and the one half no analysis can derive.

      It rides this seam for the reason GeneratorCatalog.generatorCardinality(java.lang.String, java.util.Map<java.lang.String, java.lang.String>) does: a generator's finiteness is declared by the generator, which lives above this module, and the registry that produces its rows is the same object that answers here — so the two halves of the pipeline cannot disagree about which relations are infinite.

      The default is Boundedness.UNKNOWN, which is what a catalog that knows no generators honestly has to say. That is not the conservatism the planner wants: a check that refuses an unbounded input reads an unrecognised leaf as BOUNDED rather than risk rejecting a legal query, while a catalog reporting a fact about a generator it has never heard of would simply be making it up.

      Specified by:
      generatorBoundedness in interface GeneratorCatalog
      Parameters:
      name - the generator name; case-insensitive
      args - the raw generator arguments
      Returns:
      its boundedness, or Boundedness.UNKNOWN for a generator this catalog does not know