While IPv6 address normalization was originally planned, this was deemed
too much effort to bother with such a niche feature; IPv6 addresses are
instead passed through unmodified
Experience has proved programmatically setting joins is not useful, and
getting the types and values of query parts was not being maintained.
The programmatic setting of GROUP BY may be useful in future, however.
- Each parameter is checked for type and normalized
- Interval strings are converted to DateInterval objects
- Timeouts can be specified as interval strings
- Most intervals can be null to signify infinity
- Driver classes are checked that they implement the correct interface
- Short driver names may be used, and are used by default
- Helpful errors messages are printed in case of erroneous configuration
Exporting is currently broken; this will be fixed in an upcoming commit
This involved changes to the driver interface as well as the database
schemata. The most significantly altered queries were for article
selection and marking, which relied upon unusual features of SQLite.
Overall query efficiency should not be adversely affected (it may have
even imprved) in the common case, while very rare cases (not presently
triggered by any REST handlers) require more queries.
One notable benefit of these changes is that functions which query
articles can now have complete control over which columns are returned.
This has not, however, been implemented yet: symbolic column groups are
still used for now.
Note that PostgreSQL still fails many tests, but the test suite runs to
completion. Note also that one line of the Database class is not
covered; later changes will eventually make it easier to cover the line
in question.
- Changed 'transform' method to use ValueInfo throughout. This fixes a number of obscure bugs
- Changed the 'add' and 'sub' methods to default to "now" rather than null. This means null passes through rather than being interpreted as the current time, to be consistent with other date tools
- Also changed the 'add' and 'sub' methods so that they operate correctly with invalid date strings
- Added tests for the class; improves #66
- Modified TTRSS tests because the "iso8601" format string in ValueInfo is different from Date's older format
Also move date formats to the ValueInfo class
Standardizing on immutables avoids any possible ambiguity in the API of the resultant value, as well as any ambiguity as to whether a DateTime output instance is the same instance or a clone (they had been clones)
This sees the addition of a dateOutFormat parameter to ValueInfo::normalize(), as well as a general simplification of how parameter binding works.
Some value type-casting results are slightly different, but this simply makes SQL statement objects consistent with the rest of the system.
Code coverage information is now gathered via phpdbg (a separate executable) by if available rather than xdebug, as the latter is hard to turn on and off.
A "test:quick" task has also been added to Robo, which excludes 31 tests which together account for almost two thirds of the test run time. This should pave the way for testing to be added as a commit hook for Git.
Includes PHPDoc license tag in the file-level block with accompanying copyright notice.
Also added an AUTHORS file on the off chance of outside contributions
This required adding the "notes" column to the arsse_marks table and adding same as a target value in Database::articleMark()
The Context class was also adjusted to remove the possibility of false positives in some tests
This method provides generalized, consistent type casting more versatile than PHP's basic type juggling while hiding the significant complexity in achieving this.
While this commit does not change any existing code to use the new method, the intent is for both API handlers and database drivers to use the same basic rules for type conversion while still allowing for differing failure modes.
Also consolidated article star counting into a generic articleCount function which accepts a context.
This may lead to slight efficiency losses in either listing or marking (and more significant ones in counting starred), but the advantages of centralized context handling are significant with the future addition of labels and the need to count articles under various future contexts in TTRSS.
