feat!: change TYPE_NAME visibility

[seb-jean]

Currently, I need to do this in my Doctrine entity:

#[ORM\Column(type: 'point')]
public PointValueObject $point;

It would be interesting to do this:

#[ORM\Column(type: Point::TYPE_NAME)]
public PointValueObject $point;

Summary by CodeRabbit

• Refactor
  • Made type identifier constants publicly accessible across all DBAL types, improving discoverability for integrations and external tooling; no functional behavior changes.

[coderabbitai]

Walkthrough

Visibility of the TYPE_NAME constant was changed from protected to public across many DBAL type classes and anonymous test classes; constant values and code logic remain unchanged.

Changes

Cohort / File(s)	Change Summary
Base Type src/MartinGeorgiev/Doctrine/DBAL/Types/BaseType.php	TYPE_NAME constant visibility changed from protected → public.
Array Types src/MartinGeorgiev/Doctrine/DBAL/Types/*Array.php (e.g. BigIntArray.php, BooleanArray.php, CidrArray.php, InetArray.php, IntegerArray.php, JsonbArray.php, MacaddrArray.php, PointArray.php, RealArray.php, SmallIntArray.php, TextArray.php, DoublePrecisionArray.php)	TYPE_NAME constant visibility changed from protected → public.
Scalar / Other Types src/MartinGeorgiev/Doctrine/DBAL/Types/Cidr.php, Inet.php, Jsonb.php, Macaddr.php, Point.php	TYPE_NAME constant visibility changed from protected → public.
Unit Tests (anonymous classes) tests/Unit/MartinGeorgiev/Doctrine/DBAL/Types/BaseNetworkTypeArrayTest.php, tests/Unit/MartinGeorgiev/Doctrine/DBAL/Types/BaseTypeTest.php	TYPE_NAME constant visibility in anonymous test subclasses changed from protected → public.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Files/areas to spot-check:

• BaseType.php (ensure public constant use doesn't break API expectations).
• Representative concrete type files (e.g., Jsonb.php, IntegerArray.php) to verify no accidental edits beyond visibility.
• Tests that define anonymous classes to confirm assertions still valid.

Possibly related PRs

• chore: test the BaseType and BaseFunction abstractions #309 — Related tests and TYPE_NAME visibility adjustments referenced/affected by this change.
• feat: add support for arrays of REAL and DOUBLE PRECISION #307 — Overlaps with visibility changes for specific array types (e.g., DoublePrecisionArray, RealArray).
• chore: upgrade PHPStan and Rector to v2 #289 — Previous changes touching TYPE_NAME declarations across types.

Poem

I hopped through constants, gentle and quick,
From hidden to public, a tiny trick.
TYPE_NAME now waves in broad daylight,
Arrays and points gleam tidy and bright.
A rabbit’s cheer for one small tweak — hop, click! 🐇✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'feat!: change TYPE_NAME visibility' clearly and concisely describes the primary change across all affected files—making the TYPE_NAME constant public instead of protected.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coveralls]

coverage: 93.789%. remained the same
when pulling de52f4c on seb-jean:feat/type-name-visibility
into 8dbbf8c on martin-georgiev:main.

[martin-georgiev]

Currently, I disagree with this change - due to a single use case, the change unnecessarily alters the visibility of a constant that was not intended to be public.

[seb-jean]

Currently, I disagree with this change - due to a single use case, the change unnecessarily alters the visibility of a constant that was not intended to be public.

This is something that is done in Doctrine DBAL: https://github.com/doctrine/dbal/blob/4.2.x/src/Types/Types.php#L12-L36

This allows you to avoid making a mistake in the name of the data type.

[martin-georgiev]

This is a potentially breaking change. It won't get merged until the next major version bump, which I don't expect to happen soon. A better solution would be to introduce a new Types enum/class exactly in the same way as it is done for Doctrine, and refactor the TYPE_NAME constants so they reuse the new constants defined in that Types.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

src/MartinGeorgiev/Doctrine/DBAL/Types/Jsonb.php (1)

24-24: Follow the maintainer's proposed alternative approach.

The visibility change is technically correct, but the maintainer has explicitly indicated this approach conflicts with the intended API design. The TYPE_NAME constant was intentionally protected as an implementation detail.

As discussed in the PR comments, consider implementing the maintainer's suggested alternative: introduce a new Types enum or class (similar to Doctrine DBAL's pattern) that defines public type-name constants. The existing TYPE_NAME constants in each class can then reference those public constants internally without changing their visibility. This approach:

• Provides the public API you need for Doctrine attributes
• Maintains the separation between public API and implementation details
• Follows established Doctrine DBAL patterns
• Avoids expanding the API surface of each type class

src/MartinGeorgiev/Doctrine/DBAL/Types/BooleanArray.php (1)

22-22: Consider the alternative approach proposed by the maintainer.

While the visibility change is syntactically correct, expanding the public API surface for TYPE_NAME has long-term implications. Once public, this constant becomes part of the API contract and any future modifications would be breaking changes.

The maintainer proposed an alternative solution: introduce a dedicated Types class/enum with public type-name constants (mirroring Doctrine DBAL's pattern), then refactor existing protected TYPE_NAME constants to reference those new public constants. This approach would:

• Provide the type-safe entity attribute usage you're seeking
• Avoid changing existing constant visibility
• Create an explicit, intentional public API for type names
• Maintain clearer separation between internal implementation and public interface

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 84edac7 and bc09ffa.

📒 Files selected for processing (5)

• src/MartinGeorgiev/Doctrine/DBAL/Types/BooleanArray.php (1 hunks)
• src/MartinGeorgiev/Doctrine/DBAL/Types/Jsonb.php (1 hunks)
• src/MartinGeorgiev/Doctrine/DBAL/Types/JsonbArray.php (1 hunks)
• src/MartinGeorgiev/Doctrine/DBAL/Types/Point.php (1 hunks)
• src/MartinGeorgiev/Doctrine/DBAL/Types/TextArray.php (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• src/MartinGeorgiev/Doctrine/DBAL/Types/TextArray.php

🧰 Additional context used

🧠 Learnings (7)

📓 Common learnings

Learnt from: martin-georgiev
Repo: martin-georgiev/postgresql-for-doctrine PR: 421
File: docs/AVAILABLE-TYPES.md:31-33
Timestamp: 2025-08-19T13:07:15.184Z
Learning: In martin-georgiev/postgresql-for-doctrine, the AVAILABLE-TYPES.md documentation table's second column shows DBAL type names (what TYPE_NAME constants contain and getName() method returns) not PostgreSQL internal catalogue names. Array types use the format like 'text[]', 'jsonb[]', 'inet[]' - not the underscore-prefixed PostgreSQL internal names like '_text', '_jsonb', '_inet'.

Learnt from: martin-georgiev
Repo: martin-georgiev/postgresql-for-doctrine PR: 421
File: docs/AVAILABLE-TYPES.md:31-33
Timestamp: 2025-08-19T13:07:15.184Z
Learning: In martin-georgiev/postgresql-for-doctrine, the point[] array type should be documented as "point[]" not "_point" in the AVAILABLE-TYPES.md table, to be consistent with all other array types like text[], jsonb[], inet[], etc.

Learnt from: martin-georgiev
Repo: martin-georgiev/postgresql-for-doctrine PR: 421
File: docs/AVAILABLE-TYPES.md:31-33
Timestamp: 2025-08-19T13:07:15.184Z
Learning: In martin-georgiev/postgresql-for-doctrine, the AVAILABLE-TYPES.md documentation table's second column shows DBAL type names (what getName() method returns) not PostgreSQL internal catalogue names. Array types use the format like 'text[]', 'jsonb[]', 'inet[]' - not the underscore-prefixed PostgreSQL internal names like '_text', '_jsonb', '_inet'.

Learnt from: martin-georgiev
Repo: martin-georgiev/postgresql-for-doctrine PR: 421
File: docs/AVAILABLE-TYPES.md:31-33
Timestamp: 2025-08-19T13:07:15.184Z
Learning: In martin-georgiev/postgresql-for-doctrine, the AVAILABLE-TYPES.md documentation table's second column shows DBAL type names (what getName() method returns) not PostgreSQL internal catalogue names. Array types use the format like 'text[]', 'jsonb[]', 'inet[]' - not the underscore-prefixed PostgreSQL internal names like '_text', '_jsonb', '_inet'.

📚 Learning: 2025-08-19T13:07:15.184Z

Learnt from: martin-georgiev
Repo: martin-georgiev/postgresql-for-doctrine PR: 421
File: docs/AVAILABLE-TYPES.md:31-33
Timestamp: 2025-08-19T13:07:15.184Z
Learning: In martin-georgiev/postgresql-for-doctrine, the AVAILABLE-TYPES.md documentation table's second column shows DBAL type names (what TYPE_NAME constants contain and getName() method returns) not PostgreSQL internal catalogue names. Array types use the format like 'text[]', 'jsonb[]', 'inet[]' - not the underscore-prefixed PostgreSQL internal names like '_text', '_jsonb', '_inet'.

Applied to files:

• src/MartinGeorgiev/Doctrine/DBAL/Types/Jsonb.php
• src/MartinGeorgiev/Doctrine/DBAL/Types/JsonbArray.php
• src/MartinGeorgiev/Doctrine/DBAL/Types/Point.php
• src/MartinGeorgiev/Doctrine/DBAL/Types/BooleanArray.php

📚 Learning: 2025-08-19T13:07:15.184Z

Learnt from: martin-georgiev
Repo: martin-georgiev/postgresql-for-doctrine PR: 421
File: docs/AVAILABLE-TYPES.md:31-33
Timestamp: 2025-08-19T13:07:15.184Z
Learning: In martin-georgiev/postgresql-for-doctrine, the AVAILABLE-TYPES.md documentation table's second column shows DBAL type names (what getName() method returns) not PostgreSQL internal catalogue names. Array types use the format like 'text[]', 'jsonb[]', 'inet[]' - not the underscore-prefixed PostgreSQL internal names like '_text', '_jsonb', '_inet'.

Applied to files:

• src/MartinGeorgiev/Doctrine/DBAL/Types/Jsonb.php
• src/MartinGeorgiev/Doctrine/DBAL/Types/JsonbArray.php
• src/MartinGeorgiev/Doctrine/DBAL/Types/BooleanArray.php

📚 Learning: 2025-03-26T02:46:12.804Z

Learnt from: martin-georgiev
Repo: martin-georgiev/postgresql-for-doctrine PR: 0
File: :0-0
Timestamp: 2025-03-26T02:46:12.804Z
Learning: The PR "preserve the type of floats and integers when transforming back and forth between PostgreSQL and PHP" improves type handling by ensuring that integers remain integers, floats remain floats, numeric strings stay as strings, and booleans are properly converted through the transformation process.

Applied to files:

• src/MartinGeorgiev/Doctrine/DBAL/Types/Jsonb.php

📚 Learning: 2025-08-19T13:07:15.184Z

Learnt from: martin-georgiev
Repo: martin-georgiev/postgresql-for-doctrine PR: 421
File: docs/AVAILABLE-TYPES.md:31-33
Timestamp: 2025-08-19T13:07:15.184Z
Learning: In martin-georgiev/postgresql-for-doctrine, the point[] array type should be documented as "point[]" not "_point" in the AVAILABLE-TYPES.md table, to be consistent with all other array types like text[], jsonb[], inet[], etc.

Applied to files:

• src/MartinGeorgiev/Doctrine/DBAL/Types/JsonbArray.php
• src/MartinGeorgiev/Doctrine/DBAL/Types/Point.php
• src/MartinGeorgiev/Doctrine/DBAL/Types/BooleanArray.php

📚 Learning: 2025-09-06T22:15:32.757Z

Learnt from: martin-georgiev
Repo: martin-georgiev/postgresql-for-doctrine PR: 443
File: tests/Unit/MartinGeorgiev/Utils/PostgresArrayToPHPArrayTransformerTest.php:169-172
Timestamp: 2025-09-06T22:15:32.757Z
Learning: In martin-georgiev/postgresql-for-doctrine, TextArray users should expect the database to normalize data to strings only. The design assumes that intended PHP data for TextArray is always strings, not other data types, which is a reasonable tradeoff that aligns with PostgreSQL text[] type semantics.

Applied to files:

• src/MartinGeorgiev/Doctrine/DBAL/Types/JsonbArray.php
• src/MartinGeorgiev/Doctrine/DBAL/Types/BooleanArray.php

📚 Learning: 2025-08-24T16:52:32.488Z

Learnt from: martin-georgiev
Repo: martin-georgiev/postgresql-for-doctrine PR: 0
File: :0-0
Timestamp: 2025-08-24T16:52:32.488Z
Learning: This repository uses BaseType extension pattern for custom Doctrine DBAL types with PostgreSQL platform assertions, comprehensive unit and integration testing with data providers, and dedicated exception classes for type conversion errors.

Applied to files:

• src/MartinGeorgiev/Doctrine/DBAL/Types/Point.php

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)

• GitHub Check: PHP 8.3 + Doctrine ORM 2.18 + Doctrine Lexer 3.0
• GitHub Check: PHP 8.3 + Doctrine ORM 2.18 + Doctrine Lexer 2.1
• GitHub Check: PHP 8.2 + Doctrine ORM latest + Doctrine Lexer 3.0
• GitHub Check: PHP 8.2 + Doctrine ORM 2.18 + Doctrine Lexer 3.0
• GitHub Check: PHP 8.1 + Doctrine ORM 2.14 + Doctrine Lexer 2.1
• GitHub Check: Code Quality
• GitHub Check: wait-for-tests-worflows-before-upload

🔇 Additional comments (2)

src/MartinGeorgiev/Doctrine/DBAL/Types/Point.php (1)

23-23: Consider the alternative approach suggested by the maintainer.

While the implementation is clean, the PR comments indicate the maintainer objects to changing TYPE_NAME visibility, as it was intentionally protected. The maintainer proposed an alternative: introduce a new Types enum/class (mirroring Doctrine DBAL's pattern) with public type-name constants, then refactor existing TYPE_NAME constants to reference those new public constants.

This approach would achieve the goal of providing public constants for use in entity attributes without altering the existing protected API contract.

Please confirm whether you'd like to proceed with the maintainer's suggested alternative before continuing with this visibility change approach.

src/MartinGeorgiev/Doctrine/DBAL/Types/JsonbArray.php (1)

22-22: The review comment is unsupported by verifiable evidence and should be disregarded.

The TYPE_NAME visibility change from protected to public was already committed in commit fc7b44f and is part of the current branch history. The review comment's claims about maintainer objections to this approach and a proposed Types enum/class alternative cannot be verified in the codebase or accessible PR context. No such alternative exists, and no evidence of objections from the maintainer is available. The change has already been made and integrated.

Likely an incorrect or invalid review comment.