-
-
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
Identity columns #4744
Comments
Not sure why I originally made the title so shouty, this isn't SQL |
This looks a bit misleading given that there is an API for that: dbal/src/Platforms/AbstractPlatform.php Line 3056 in e974d4d
It's implemented natively by the SQL Server and IBM DB2 platforms: dbal/src/Platforms/SQLServer2012Platform.php Lines 1305 to 1308 in e974d4d
dbal/src/Platforms/DB2Platform.php Lines 176 to 180 in e974d4d
Most of the platforms implement it in their proprietary terms (e.g. MySQL, SQLite) and only PostgreSQL and Oracle currently emulate it via sequences. I believe, the issue is about implementing native support where it's missing, right? |
Yes, you're right, what's missing is native support for the SQL standard (as opposed to PG-specific |
I believe it's not problem #1 from the DBAL perspective: as long as it behaves as the identity column, it shouldn't be a problem from the API standpoint. For instance, MySQL and SQLite will keep using their own syntax anyways. What's more important is that as long as not all platforms support identity columns, the API consumers have to use two different APIs to achieve effectively the same goal (identity generation) on different platforms. That's the problem I'd like to solve by eventually deprecating Additionally, the identity columns will need the support for From the article linked to #2695:
This is effectively how identity columns are currently implemented in the PostgreSQL platform. Switching to the standard SQL syntax wherever possible would be the cherry on the cake. Note, that it's a breaking change.
Sounds good. This also could be addressed closer to the end. |
Because it will make the diff between a database and its in-memory equivalent not empty, and will suddenly generate a lot of migrations when using |
Yes. Handling this diff automatically in the DBAL may be non-trivial: not only we'd have to properly migrate the table, trigger definitions, etc. we'd have to migrate their state (i.e. next sequence value). It might be easier to document a manual migration path, although even this will take quite some time. |
@morozov it doesn't look too bad.
where |
@bendavies if you want to give it a try, go for it. |
Apologies. I didn't realise comments weren't welcome unless accompanied by a PR. Let me know if you'd like me to delete my comment. |
Not at all. Thank you for the details. |
Apologies for my irritability. Rough day |
Feature Request
Summary
As of now, it seems that identity columns are not supported by the DBAL. This feature is available since Oracle 12.1 and PostgreSQL 10.
Supposed pros:
SERIAL
, they are standardThe text was updated successfully, but these errors were encountered: