-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DOCS] Fix binary type format documentation #6700
Conversation
| [2] [6] | +--------------------------+ +----------------------------------------------------------+ | ||
| | | **SQL Server** | | ``BINARY(n)`` [4] | | ||
| | +--------------------------+ +----------------------------------------------------------+ | ||
| | | **Oracle** | *all* | ``RAW(n)`` | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Previously, BINARY
and RAW
were grouped together (I don't know why though). Now that's no longer the case. Shouldn't the solution be to make the first cell bigger so that it lines up the ones in the "name" column?
@derrabus @morozov would you maybe know why there was this grouping / what rendering is the goal here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If they need to be grouped we can simply remove the separator between the types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe the presentation of binary
needs an update. I'd interpret the old style like SQL Server shares VARBINARY and BINARY, but RAW is afaik unknown to SQL Server.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've never gotten into the details of this documentation but FWIW, RAW
applies only to Oracle while BINARY
and VARBINARY
apply only to MySQL and SQL Server (see getBinaryTypeDeclarationSQLSnippet()
).
It looks like we need to split the version column that spans three rows into two (one to span MySQL and SQL Server) and the other dedicated to Oracle. Then it should be accurate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, quite likely, the PHP type for the BINARY
data type is never resource
(it was the case in older DBAL versions). Right now, it should support only string
.
Should this be squashed into one commit? I'm not sure if the commit history in the PR is helpful. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Squash would be nice
The table contained an error which broke the parsing of the table. Row content cannot be at the same line as the row span definition.
2a03cfc
to
61dcd2a
Compare
Squashed :-) |
Thanks for fixing this super long standing issue! |
Is there anything needed to get this at the website? You might want to upgrade the phpDocumentor/guides packages in the site so you get some extra fixes impacting tables. |
A cronjob should publish the new version overnight. Thanks for the fixes! |
@jaapio the result can be seen here: https://www.doctrine-project.org/projects/doctrine-dbal/en/4.2/reference/types.html#mapping-matrix :) |
The table contained an error which broke the parsing of the table. Row content cannot be at the same line as the row span definition.
The rendered table looks unstyled like this, I checked this directly with the phpdocumentor/guides project so no doctrine styling is included in the screenshot.