data-contract-validator 1.1.0__tar.gz → 1.1.1__tar.gz

{data_contract_validator-1.1.0 → data_contract_validator-1.1.1}/CHANGELOG.md

@@ -7,6 +7,16 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [1.1.1] - 2026-06-30
+
+### Added
+- **Automatic plural/singular table & column matching.** dbt models are
+  conventionally plural (`users`) while Pydantic classes are singular
+  (`User` → `user`); these now match automatically with no `mapping` needed.
+  Candidate forms are only matched against names that actually exist on the
+  other side, so it never over-strips (`address` is never mistaken for
+  `addres`). Explicit `mapping` still takes precedence.
+
 ## [1.1.0] - 2026-06-30
 
 This release is focused on **accuracy** — making a red check always mean a real
@@ -115,7 +125,8 @@ deploy.
 - Limited type inference from SQL
 - No support for complex nested types
 
-[Unreleased]: https://github.com/OGsiji/data-contract-validator/compare/v1.1.0...HEAD
+[Unreleased]: https://github.com/OGsiji/data-contract-validator/compare/v1.1.1...HEAD
+[1.1.1]: https://github.com/OGsiji/data-contract-validator/releases/tag/v1.1.1
 [1.1.0]: https://github.com/OGsiji/data-contract-validator/releases/tag/v1.1.0
 [1.0.5]: https://github.com/OGsiji/data-contract-validator/releases/tag/v1.0.5
 [1.0.0]: https://github.com/OGsiji/data-contract-validator/releases/tag/v1.0.0

{data_contract_validator-1.1.0/data_contract_validator.egg-info → data_contract_validator-1.1.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: data-contract-validator
-Version: 1.1.0
+Version: 1.1.1
 Summary: Validate data contracts between dbt models and FastAPI/Pydantic APIs with accurate, low-false-positive schema checks
 Author-email: Ogunniran Siji <ogunniransiji@gmail.com>
 Maintainer-email: Ogunniran Siji <ogunniransiji@gmail.com>
@@ -201,10 +201,13 @@ validation:
 
 ### When do I need `mapping`?
 
-By default, names are matched across `snake_case` / `camelCase` / casing
-(`UserAnalytics` → `user_analytics`, `userId` → `user_id`). Reach for `mapping`
-only when a model or column is named so differently that the convention can't
-bridge it (e.g. Pydantic `user_id` ↔ dbt `customer_identifier`).
+Most of the time you don't. Names are matched automatically across:
+- `snake_case` / `camelCase` / casing — `UserAnalytics` → `user_analytics`, `userId` → `user_id`
+- **plural ↔ singular** — dbt's plural `users` matches Pydantic's `User` (→ `user`)
+  with no config (and it won't over-match — `address` is never confused with `addres`).
+
+Reach for `mapping` only when a model or column is named so differently that
+convention can't bridge it (e.g. Pydantic `user_id` ↔ dbt `customer_identifier`).
 
 ## 🐍 Python API
 

{data_contract_validator-1.1.0 → data_contract_validator-1.1.1}/README.md

@@ -151,10 +151,13 @@ validation:
 
 ### When do I need `mapping`?
 
-By default, names are matched across `snake_case` / `camelCase` / casing
-(`UserAnalytics` → `user_analytics`, `userId` → `user_id`). Reach for `mapping`
-only when a model or column is named so differently that the convention can't
-bridge it (e.g. Pydantic `user_id` ↔ dbt `customer_identifier`).
+Most of the time you don't. Names are matched automatically across:
+- `snake_case` / `camelCase` / casing — `UserAnalytics` → `user_analytics`, `userId` → `user_id`
+- **plural ↔ singular** — dbt's plural `users` matches Pydantic's `User` (→ `user`)
+  with no config (and it won't over-match — `address` is never confused with `addres`).
+
+Reach for `mapping` only when a model or column is named so differently that
+convention can't bridge it (e.g. Pydantic `user_id` ↔ dbt `customer_identifier`).
 
 ## 🐍 Python API
 

{data_contract_validator-1.1.0 → data_contract_validator-1.1.1}/data_contract_validator/__init__.py

@@ -5,7 +5,7 @@ Prevent production API breaks by validating data contracts between
 your data pipelines and API frameworks.
 """
 
-__version__ = "1.1.0"
+__version__ = "1.1.1"
 __author__ = "Ogunniran Siji"
 __email__ = "ogunniransiji@gmail.com"
 

{data_contract_validator-1.1.0 → data_contract_validator-1.1.1}/data_contract_validator/core/types.py

@@ -14,7 +14,7 @@ the tool stays quiet rather than crying wolf.
 
 from enum import Enum
 import re
-from typing import Optional
+from typing import Any, Dict, List, Optional
 
 
 class CanonicalType(Enum):
@@ -289,3 +289,59 @@ def normalize_name(name: Optional[str]) -> str:
     text = re.sub(r"(.)([A-Z][a-z]+)", r"\1_\2", text)
     text = re.sub(r"([a-z0-9])([A-Z])", r"\1_\2", text)
     return text.lower().strip()
+
+
+def name_variants(name: Optional[str]) -> List[str]:
+    """Return candidate forms of a name for plural/singular-insensitive matching.
+
+    dbt models are conventionally plural (``users``) while Pydantic classes are
+    singular (``User`` -> ``user``); this bridges that gap automatically.
+
+    The normalized form is always first (so exact matches win). The remaining
+    plural/singular candidates are deliberately over-generated -- callers should
+    only treat a candidate as a match if it equals a name that *actually exists*
+    on the other side, which makes spurious forms (e.g. ``statu`` from
+    ``status``) harmless rather than dangerous.
+    """
+    n = normalize_name(name)
+    variants: List[str] = [n] if n else []
+
+    def add(value: str) -> None:
+        if value and value not in variants:
+            variants.append(value)
+
+    if not n:
+        return variants
+
+    # Pluralize.
+    if n.endswith("y") and len(n) > 1 and n[-2] not in "aeiou":
+        add(n[:-1] + "ies")  # category -> categories
+    if n.endswith(("s", "x", "z", "ch", "sh")):
+        add(n + "es")  # address -> addresses, box -> boxes
+    add(n + "s")  # user -> users
+
+    # Singularize.
+    if n.endswith("ies") and len(n) > 4:
+        add(n[:-3] + "y")  # categories -> category
+    if n.endswith("es") and len(n) > 3:
+        add(n[:-2])  # addresses -> address, boxes -> box
+    if n.endswith("s") and not n.endswith("ss") and len(n) > 2:
+        add(n[:-1])  # users -> user (but never address -> addres)
+
+    return variants
+
+
+def find_match(name: str, index: Dict[str, Any]) -> Any:
+    """Look up ``name`` in an index keyed by normalized names.
+
+    Prefers an exact normalized match, then falls back to a plural/singular
+    variant that actually exists in the index. Returns the matched value or
+    ``None``.
+    """
+    n = normalize_name(name)
+    if n in index:
+        return index[n]
+    for variant in name_variants(name):
+        if variant in index:
+            return index[variant]
+    return None

{data_contract_validator-1.1.0 → data_contract_validator-1.1.1}/data_contract_validator/core/validator.py

@@ -4,7 +4,13 @@ Core validation logic for comparing schemas.
 
 from typing import Dict, List, Optional, Any
 from .models import ValidationResult, ValidationIssue, IssueSeverity, Schema
-from .types import CanonicalType, normalize_name, normalize_sql_type, types_compatible
+from .types import (
+    CanonicalType,
+    find_match,
+    normalize_name,
+    normalize_sql_type,
+    types_compatible,
+)
 from ..extractors.base import BaseExtractor
 
 
@@ -107,11 +113,11 @@ class ContractValidator:
         """Validate a single table."""
         print(f"  🔍 Validating table: {table_name}")
 
-        # Resolve the source table: explicit mapping first, else normalized name.
+        # Resolve the source table: explicit mapping first, then exact normalized
+        # name, then a plural/singular variant (users <-> user).
         target_norm = normalize_name(table_name)
         mapped_source = self.table_map.get(target_norm)
-        lookup_norm = normalize_name(mapped_source) if mapped_source else target_norm
-        source_schema = source_by_norm.get(lookup_norm)
+        source_schema = find_match(mapped_source or table_name, source_by_norm)
         if not source_schema:
             hint = f" (mapped to source '{mapped_source}')" if mapped_source else ""
             self.issues.append(
@@ -152,11 +158,12 @@ class ContractValidator:
         check_types = source_schema.confidence != "low"
 
         for col_norm, col_info in target_columns.items():
-            # Apply an explicit column mapping for this target column, if any.
+            # Apply an explicit column mapping for this target column, if any,
+            # then match by exact name, then by plural/singular variant.
             override = col_overrides.get(col_norm)
-            source_key = normalize_name(override) if override else col_norm
+            source_col = find_match(override or col_info["name"], source_columns)
 
-            if source_key not in source_columns:
+            if source_col is None:
                 is_required = col_info.get("required", True)
                 if is_required and source_complete:
                     severity = IssueSeverity.CRITICAL
@@ -188,7 +195,6 @@ class ContractValidator:
                     )
                 )
             elif check_types:
-                source_col = source_columns[source_key]
                 if not self._columns_type_compatible(source_col, col_info):
                     self.issues.append(
                         ValidationIssue(

{data_contract_validator-1.1.0 → data_contract_validator-1.1.1/data_contract_validator.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: data-contract-validator
-Version: 1.1.0
+Version: 1.1.1
 Summary: Validate data contracts between dbt models and FastAPI/Pydantic APIs with accurate, low-false-positive schema checks
 Author-email: Ogunniran Siji <ogunniransiji@gmail.com>
 Maintainer-email: Ogunniran Siji <ogunniransiji@gmail.com>
@@ -201,10 +201,13 @@ validation:
 
 ### When do I need `mapping`?
 
-By default, names are matched across `snake_case` / `camelCase` / casing
-(`UserAnalytics` → `user_analytics`, `userId` → `user_id`). Reach for `mapping`
-only when a model or column is named so differently that the convention can't
-bridge it (e.g. Pydantic `user_id` ↔ dbt `customer_identifier`).
+Most of the time you don't. Names are matched automatically across:
+- `snake_case` / `camelCase` / casing — `UserAnalytics` → `user_analytics`, `userId` → `user_id`
+- **plural ↔ singular** — dbt's plural `users` matches Pydantic's `User` (→ `user`)
+  with no config (and it won't over-match — `address` is never confused with `addres`).
+
+Reach for `mapping` only when a model or column is named so differently that
+convention can't bridge it (e.g. Pydantic `user_id` ↔ dbt `customer_identifier`).
 
 ## 🐍 Python API
 

{data_contract_validator-1.1.0 → data_contract_validator-1.1.1}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "data-contract-validator"
-version = "1.1.0"
+version = "1.1.1"
 description = "Validate data contracts between dbt models and FastAPI/Pydantic APIs with accurate, low-false-positive schema checks"
 readme = "README.md"
 license = {text = "MIT"}