API Reference¶
This page is generated from the source docstrings with
sphinx.ext.autodoc.
It covers the modules that make up the engine described in
Architecture: the internal data models, the schema
analyzer, the generator factory, the post-generation constraint check, and
the defensive fallback manager. The REST surface built on top of these
modules is documented separately in /docs (Swagger UI) when the FastAPI
app is running; see FastAPI.
Core data models¶
Core data models for V4 adaptive framework.
- class test_data_workbench.core.models.EntityType(*values)[source]¶
Bases:
EnumCommon e-commerce entity types for classification.
- USER = 'user'¶
- CUSTOMER = 'customer'¶
- PRODUCT = 'product'¶
- ORDER = 'order'¶
- REVIEW = 'review'¶
- CATEGORY = 'category'¶
- INVENTORY = 'inventory'¶
- PAYMENT = 'payment'¶
- SHIPPING = 'shipping'¶
- ANALYTICS = 'analytics'¶
- UNKNOWN = 'unknown'¶
- class test_data_workbench.core.models.ConstraintType(*values)[source]¶
Bases:
EnumDatabase constraint types.
- PRIMARY_KEY = 'primary_key'¶
- FOREIGN_KEY = 'foreign_key'¶
- UNIQUE = 'unique'¶
- NOT_NULL = 'not_null'¶
- CHECK = 'check'¶
- INDEX = 'index'¶
- class test_data_workbench.core.models.Column(name: str, data_type: str, nullable: bool = True, default: str | None = None, max_length: int | None = None, constraints: List[ConstraintType] = <factory>, sample_values: List[Any] = <factory>)[source]¶
Bases:
objectDatabase column metadata.
- constraints: List[ConstraintType]¶
- class test_data_workbench.core.models.Relationship(from_table: str, to_table: str, from_column: str, to_column: str, relationship_type: str, strength: float = 1.0)[source]¶
Bases:
objectTable relationship metadata.
- class test_data_workbench.core.models.Table(name: str, columns: ~typing.List[~test_data_workbench.core.models.Column], row_count: int | None = 0, entity_type: ~test_data_workbench.core.models.EntityType = EntityType.UNKNOWN, relationships: ~typing.List[~test_data_workbench.core.models.Relationship] = <factory>)[source]¶
Bases:
objectDatabase table metadata.
- entity_type: EntityType = 'unknown'¶
- relationships: List[Relationship]¶
- class test_data_workbench.core.models.BusinessRule(rule_id: str, description: str, rule_type: str, affected_columns: ~typing.List[str], confidence: float, examples: ~typing.List[str] = <factory>)[source]¶
Bases:
objectInferred business rule from data analysis.
- class test_data_workbench.core.models.PIIColumn(table: str, column: str, category: str)[source]¶
Bases:
objectA column flagged as likely containing personally identifiable information, based on a name-based heuristic (no row data needed).
- class test_data_workbench.core.models.SchemaInfo(database_name: str, tables: ~typing.List[~test_data_workbench.core.models.Table], relationships: ~typing.List[~test_data_workbench.core.models.Relationship], business_rules: ~typing.List[~test_data_workbench.core.models.BusinessRule], analysis_metadata: ~typing.Dict[str, ~typing.Any] = <factory>, pii_columns: ~typing.List[~test_data_workbench.core.models.PIIColumn] = <factory>)[source]¶
Bases:
objectComplete database schema analysis results.
- relationships: List[Relationship]¶
- business_rules: List[BusinessRule]¶
- property entity_types: Dict[EntityType, List[Table]]¶
Group tables by detected entity type.
- class test_data_workbench.core.models.GeneratorConfig(entity_type: EntityType, table_name: str, dependencies: List[str] = <factory>, generation_rules: Dict[str, ~typing.Any]=<factory>, fallback_config: Dict[str, ~typing.Any] | None=None)[source]¶
Bases:
objectConfiguration for a specific entity generator.
- entity_type: EntityType¶
- class test_data_workbench.core.models.ScenarioConfig(name: str, description: str, entities: ~typing.Dict[str, int], relationships: ~typing.List[str] = <factory>, constraints: ~typing.Dict[str, ~typing.Any] = <factory>)[source]¶
Bases:
objectBusiness scenario configuration.
- class test_data_workbench.core.models.AdaptationResult(schema_info: ~test_data_workbench.core.models.SchemaInfo, generated_code: ~typing.Dict[str, str], config_files: ~typing.Dict[str, str], templates: ~typing.Dict[str, str], analysis_time: float, success: bool, errors: ~typing.List[str] = <factory>, constraint_check_summary: str | None = None)[source]¶
Bases:
objectResults from rapid adaptation workflow.
- schema_info: SchemaInfo¶
- class test_data_workbench.core.models.ValidationResult(valid: bool, errors: List[str] = <factory>, warnings: List[str] = <factory>, suggestions: List[str] = <factory>)[source]¶
Bases:
objectResults from team contribution validation.
- class test_data_workbench.core.models.DemoScenario(name: str, description: str, required_features: List[str], fallback_features: List[str], demo_data: Dict[str, Any], success_criteria: List[str])[source]¶
Bases:
objectDemonstration scenario configuration.
- class test_data_workbench.core.models.DemoStatus(ready_scenarios: List[DemoScenario], blocked_scenarios: List[DemoScenario], fallback_plan: DemoScenario | None, confidence_score: float)[source]¶
Bases:
objectCurrent demonstration readiness status.
- ready_scenarios: List[DemoScenario]¶
- blocked_scenarios: List[DemoScenario]¶
- fallback_plan: DemoScenario | None¶
Schema analyzer¶
Database schema reverse-engineering for unknown production systems.
- test_data_workbench.adaptation.schema_analyzer.classify_column_pii(column_name: str) str | None[source]¶
Return the PII category for a column name, or None if it doesn’t match any known heuristic. Pure name-based check - no DB access.
When a name matches keywords from more than one category (e.g. “ip_address” and “email_address” both contain the bounded token “address”, which also belongs to the “address” category), the longest - i.e. most specific - matching keyword wins, so those are categorized as ip_address / email respectively rather than the more generic address.
- class test_data_workbench.adaptation.schema_analyzer.SchemaAnalyzer[source]¶
Bases:
objectReverse-engineer any PostgreSQL e-commerce database schema.
- async analyze_production_schema(connection_string: str, metadata_only: bool = False) SchemaInfo[source]¶
Auto-discover tables, relationships, constraints, data patterns.
When metadata_only=True, only the SQLAlchemy inspector (schema reflection: get_table_names, get_columns, get_pk_constraint, get_foreign_keys) is used to describe structure. No SELECT is issued against any table’s row data: sample values are skipped, row counts are left as None (unknown), and data-derived business rule detection is skipped entirely. PII column flagging still runs, since it is a pure column-name heuristic.
Generator factory¶
Auto-create appropriate generators from discovered schema.
- class test_data_workbench.adaptation.generator_factory.GeneratorSet(generators: Dict[str, str], dependencies: Dict[str, List[str]], configs: Dict[str, GeneratorConfig], fallback_generators: Dict[str, str])[source]¶
Bases:
objectCollection of generated Python classes and their metadata.
- configs: Dict[str, GeneratorConfig]¶
- class test_data_workbench.adaptation.generator_factory.RelationshipManager(relationships: List[Relationship], dependency_order: List[str], reference_cache: Dict[str, List[Any]])[source]¶
Bases:
objectManages foreign keys and constraints across generators.
- relationships: List[Relationship]¶
- class test_data_workbench.adaptation.generator_factory.GeneratorFactory[source]¶
Bases:
objectAuto-create appropriate generators from discovered schema.
- create_generators_from_schema(schema: SchemaInfo) GeneratorSet[source]¶
Generate Python classes for each discovered entity type.
- build_relationship_handlers(relationships: List[Relationship]) RelationshipManager[source]¶
Create foreign key and constraint management system.
Constraint check¶
Lightweight post-generation constraint validation.
Runs a small, fixed set of structural checks over an already-generated dataset - primary-key uniqueness, non-null columns populated, and foreign-key values referencing generated parent ids - without re-implementing a general-purpose schema validator. Deliberately scoped tight: these are the checks that are cheap to verify and meaningful regardless of entity type, and they are exactly the ones a hand-rolled generator is most likely to get wrong (duplicate ids, missing required fields, foreign keys pointing at nothing).
- class test_data_workbench.adaptation.constraint_check.ConstraintCheckResult(checks_passed: int = 0, checks_failed: int = 0, violations: List[str] = <factory>)[source]¶
Bases:
objectOutcome of running
check_constraints()over a generated dataset. Each check is one (table, column) or (table, relationship) assertion - not one check per record - so the counts stay meaningful for a “N checks passed” style summary.
- test_data_workbench.adaptation.constraint_check.check_constraints(schema: SchemaInfo, dataset: Dict[str, List[Dict[str, Any]]]) ConstraintCheckResult[source]¶
Validate a generated dataset against the schema’s discoverable constraints.
- Parameters:
schema – The analyzed schema (tables, columns, relationships).
dataset – table name -> list of generated record dicts, e.g. the output of calling a generated
*Generator.generate(n)for each table.
- Checks performed:
Primary-key uniqueness: no duplicate non-null primary key values within a table.
Not-null: every non-nullable column is populated (not None) in every record.
Foreign-key range: for every declared relationship, every non-null foreign key value in the child table is found among the referenced column’s generated values in the parent table.
A table present in
schemabut absent fromdatasetis simply skipped - there is nothing to check. Likewise, a relationship is skipped when either side of it has no data indataset, since there is no parent id set to check the foreign key against.
- test_data_workbench.adaptation.constraint_check.generate_sample_dataset(schema: SchemaInfo, generated_code: Dict[str, str], sample_size: int = 20) Dict[str, List[Dict[str, Any]]][source]¶
Execute generated generator source, in dependency order, to build a small in-memory sample dataset - purely so
check_constraints()has something real to check. Nothing here is written to disk.Parent tables are generated first so their primary key values can be threaded through as
reference_datato child generators that accept it (the order/review-style templates), matching howGeneratorFactory._create_order_generator()and friends expect to be wired up.Best effort by design: a table whose generator source fails to exec, defines no
*Generatorclass, or raises while generating, is simply skipped rather than aborting the whole check - a single bad generator should not take down deploy’s constraint reporting.
Defensive generator manager¶
Defensive generator management with automatic fallbacks and error isolation.
- class test_data_workbench.core.defensive_manager.GeneratorResult(data: List[Dict[str, Any]], success: bool, generator_used: str, errors: List[str], warnings: List[str])[source]¶
Bases:
objectResult from generator execution with error handling.
- class test_data_workbench.core.defensive_manager.GeneratorInfo(generator_class: Type, fallback_class: Type | None, simple_fallback: Callable, entity_type: EntityType, dependencies: List[str])[source]¶
Bases:
objectInformation about a registered generator.
- entity_type: EntityType¶
- class test_data_workbench.core.defensive_manager.DefensiveGeneratorManager(feature_flags: FeatureFlags | None = None)[source]¶
Bases:
objectManages generators with automatic fallbacks and error isolation.
- generators: Dict[str, GeneratorInfo]¶
- register_generator(entity_name: str, generator_class: Type, fallback_class: Type | None = None, entity_type: EntityType = EntityType.UNKNOWN, dependencies: List[str] = None) None[source]¶
Register a generator with optional fallback.
- generate_safely(entity_type: str, count: int, **kwargs) GeneratorResult[source]¶
Generate data with automatic fallback to simple versions on failure.
- generate_with_dependencies(entity_type: str, count: int) GeneratorResult[source]¶
Generate data respecting dependency order.