Range and MultiRange parser

[Gerych1984]

Q	A
Is bugfix?	❌
New feature?	✔️
Breaks BC?	❌

Range and MultiRange format parser for PgSql

[what-the-diff[bot]]

PR Summary

• Enhancements to ColumnSchema.php
  • Added a couple of new methods to this file called getRangeParser() and getMultiRangeParser(). These methods provide objects that help in interpreting range and multi-range values from the database.
• Introduction of MultiRangeParser.php & RangeParser.php
  • These new files introduce classes that assist in parsing and understanding values representing a series of values (ranges) and a set of such series (multi-ranges) specifically in PostgreSQL databases.
• Updates to Schema.php
  • Some constants specific to understanding range column types have been added. These definitions improve the functionality of the newly introduced RangeParser & MultiRangeParser classes.
• Addition of MultiRangeParserTest.php & RangeParserTest.php
  • These new files consist of test scenarios for the new classes MultiRangeParser and RangeParser respectively. They ensure the logic driving these classes' operation works as expected.

[codecov[bot]]

Codecov Report

Patch coverage: 94.35% and project coverage change: -0.97% :warning:

Comparison is base (adcb2ee) 100.00% compared to head (5b96d65) 99.03%. Report is 1 commits behind head on master.

Additional details and impacted files

@@              Coverage Diff              @@
##              master     #307      +/-   ##
=============================================
- Coverage     100.00%   99.03%   -0.97%     
- Complexity       200      272      +72     
=============================================
  Files             13       15       +2     
  Lines            596      722     +126     
=============================================
+ Hits             596      715     +119     
- Misses             0        7       +7     

Files Changed	Coverage Δ
src/Schema.php	100.00% <ø> (ø)
src/RangeParser.php	92.50% <92.50%> (ø)
src/MultiRangeParser.php	96.87% <96.87%> (ø)
src/ColumnSchema.php	100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[Tigrov]

Good idea to support range types 👍

1. What about user defined range types? https://www.postgresql.org/docs/current/rangetypes.html 8.17.8. Defining New Range Types
2. You should get what you insert. Do not increment or decrement the value. It is user's responsibility to have inclusive or exclusive values.
3. There is PHP class DatePeriod for date range. What about to use it for convertation?

[Gerych1984]

Good idea to support range types 👍

1. What about user defined range types? https://www.postgresql.org/docs/current/rangetypes.html 8.17.8. Defining New Range Types
2. You should get what you insert. Do not increment or decrement the value. It is user's responsibility to have inclusive or exclusive values.
3. There is PHP class DatePeriod for date range. What about to use it for convertation?

1. We need to think about this. The main problem is how to understand when it is necessary to run the data by this parser in a custom format
2. Need increment/decrement - from personal experience. If postgres returned a string (2,8), it is actually a range from 3 to 7 (and the user entered it)
3. good point, need to read/think about it. The array was left over from the first iteration where 7.4 was supported. There are a lot more possibilities now

[Gerych1984]

3. There is PHP class DatePeriod for date range. What about to use it for convertation?

Unfortunately DatePeriod can't be without StartDate, but *range can

[Tigrov]

1. We need to think about this. The main problem is how to understand when it is necessary to run the data by this parser in a custom format
2. Need increment/decrement - from personal experience. If postgres returned a string (2,8), it is actually a range from 3 to 7 (and the user entered it)
3. good point, need to read/think about it. The array was left over from the first iteration where 7.4 was supported. There are a lot more possibilities now

1. In Schema class

...
public const TYPE_RANGE = 'range';
...
protected function loadColumnSchema(array $info): ColumnSchemaInterface
{
...
    if ($info['type_type'] === 'r') {
        $column->type(self::TYPE_RANGE);
    }
...
}
...

Then you can check $column->getType() === Schema::TYPE_RANGE 2. Ok, looks increment/decrement is required 3. Got it

[Gerych1984]

1. In Schema class

...
public const TYPE_RANGE = 'range';
...
protected function loadColumnSchema(array $info): ColumnSchemaInterface
{
...
    if ($info['type_type'] === 'r') {
        $column->type(self::TYPE_RANGE);
    }
...
}
...

Then you can check $column->getType() === Schema::TYPE_RANGE

A while back I suggested adding a custom type mapper. For example, it would be more convenient for me if geometric types were immediately given as an instance of a suitable class from a given library. I think it would be more universal than to have to make a whole package for such a special case

For example somewhere in di:

$schema->setType('point', static fn (?string $value) => $value ? Point::fromText($value) : null );