Skip to content
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

Deprecated usage of DB-generated UUIDs #3212

Merged
merged 1 commit into from
Jul 12, 2018
Merged

Conversation

morozov
Copy link
Member

@morozov morozov commented Jul 11, 2018

Q A
Type improvement
BC Break no
Fixed issues #3167

@Majkl578
Copy link
Contributor

I like it. But it has an impact on ORM which has a UuidGenerator, therefore not sure about 2.8.0 milestone. :/

@morozov
Copy link
Member Author

morozov commented Jul 11, 2018

I like it. But it has an impact on ORM which has a UuidGenerator, therefore not sure about 2.8.0 milestone. :/

@Majkl578, we're going to do a minor ORM release prior to releasing DBAL 2.8.0, right? As far as I understand, the changes needed to be made to the UuidGenerator are just a replacement of the DBAL API call with Ramsey\Uuid. Is there a problem with the schedule or with the introduction of a new last minute dependency or nobody just has time for it?

@Majkl578
Copy link
Contributor

the changes needed to be made to the UuidGenerator are just a replacement of the DBAL API call with Ramsey\Uuid

Unfortunately not just that. To quote your deprecation note:

Some of the platforms produce UUIDv1, some produce UUIDv4, some produce the values which are not even UUID.

It's not consistent and it's platform dependent. So it can't simply be universally replaced by a Uuid1/Uuid4 version.

Is there a problem with the schedule or with the introduction of a new last minute dependency

This is something that can't happen in a patch release, see #3181 (comment).
We can only provide deprecation in ORM 2.7 and removal in 3.0.

@morozov
Copy link
Member Author

morozov commented Jul 11, 2018

We can only provide deprecation in ORM 2.7 and removal in 3.0.

You mean ORM 2.8 is not expected? We still can introduce new dependencies in minor releases. Besides that, is it a huge problem if ORM keeps using a deprecated feature of the DBAL? Deprecation is just a message, it's not a breaking change.

@Majkl578
Copy link
Contributor

You mean ORM 2.8 is not expected?

Exactly. ORM 2.7 will be the last, deprecation-only release, but it's not scheduled to be released anytime soon (not within weeks).

Besides that, is it a huge problem if ORM keeps using a deprecated feature of the DBAL?

Personally, I wouldn't bother, but I am pretty sure someone will rush in saying it's unacceptable.

@morozov
Copy link
Member Author

morozov commented Jul 11, 2018

@Majkl578 I removed the trigger_error() pieces and only left documentation changes.

@morozov
Copy link
Member Author

morozov commented Jul 11, 2018

Personally, I wouldn't bother, but I am pretty sure someone will rush in saying it's unacceptable.

I acknowledge that but this is unhealthy. You cannot demand the library to not tell you that you're using a deprecated API. People take those messages and errors however they are just messages.

@Majkl578
Copy link
Contributor

You cannot demand the library to not tell you that you're using a deprecated API.

I agree. But in case of ORM here, the consumers are using UuidGenerator, the fact it uses DBAL platform to generate the SQL is just an implementation detail. So they would start getting deprecations from a code they don't directly use, and at the same time ORM can't provide a fixed version without using deprecated API.

Marking it as @deprecated now and leaving trigger_error() for later 2.x release is imho more consumer-friendly at this stage. This is similar to doctrine/common, we deprecated most of the classes this way, while ORM is still using them in 2.6.y (but won't be in 2.7/3.x).


Unless UUIDs are used in stored procedures which DBAL doesn't support, there's no real benefit of DB-generated UUIDs comparing to the application-generated ones.

Use a PHP library (e.g. [ramsey/uuid](https://packagist.org/packages/ramsey/uuid)) to generate UUIDs on the application side.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest the UUID PECL instead.
It less invasive and the code is much more simple.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean it's less invasive?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I got intrigued with the "less invasive" too 😄 but DBAL would simply handle a string so it doesn't really matter which lib/extension is being used.

I'd still recommend @ramsey's lib, though. It's better documented (IMO) and supports all UUID versions (even the namespaced ones)...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also don't understand the less invasive part.
The referenced PECL extension requires setup by server admin, has no documentation on php.net, is unix-only and has last release in 2015.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It has not been updated because it does not need to be. It just works.

About less invasive, i may be unclear. Sorry. I don't like the PHP lib because there is so many code for a really simple thing.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Applies also to core libs: 90%+ of the code is just to emulate userland behaviour. If you can avoid an extension for doing something that can be done in userland, then do avoid it.

@vincentchalamon vincentchalamon mentioned this pull request Jan 25, 2019
11 tasks
rgrellmann added a commit to Rossmann-IT/dbal that referenced this pull request Apr 22, 2020
Release v2.8.0

[![Build Status](https://travis-ci.org/doctrine/dbal.svg?branch=v2.8.0)](https://travis-ci.org/doctrine/dbal)

This is a minor release of Doctrine DBAL that aggregates over 30 fixes and improvements developed over the last 3 months.

This release includes all changes of the 2.7.x series, as well as feature additions and improvements that couldn’t land in patch releases.

**Backwards Compatibility Breaks**

This doesn't contain any intentional Backwards Compatibility (BC) breaks.

**Dependency Changes**

* The dependency on [doctrine/common](https://github.com/doctrine/common) is removed. DBAL now depends on [doctrine/cache](https://github.com/doctrine/cache) and [doctrine/event-manager](https://github.com/doctrine/event-manager) instead.

Please see details in the [UPGRADE.md](UPGRADE.md) documentation.

**Deprecations**

* The usage of binary fields whose length exceeds the maximum field size on a given platform is deprecated. Please use binary fields of a size which fits all target platforms, or use blob explicitly instead.
* The usage of DB-generated UUIDs is deprecated. Their format is inconsistent across supported platforms and therefore the feature is not portable. Use a PHP library (e.g. [ramsey/uuid](https://packagist.org/packages/ramsey/uuid)) to generate UUIDs on the application side.

**New features**

* Initial support of MySQL 8.
* Initial support of PostgreSQL 11.
* Ability to evaluate arbitrary SQL expressions via `AbstractPlatform::getDummySelectSQL()`.

**Improvements and Fixes**

* Improved support of binary fields on Oracle and IBM DB2.
* Improved SQL Server configuration capabilities via both `sqlsrv` and `pdo_sqlsrv`.
* Improved handling of `AUTOINCREMENT`ed primary keys in SQLite.
* Integration tests are run against IBM DB2 on Travis CI.
* Code coverage is collected for the Oracle platform on continuousphp.

Total issues resolved: **33**

**Deprecations:**

- [3187: Deprecate usage of binary fields whose length exceeds maximum](doctrine#3187) thanks to @morozov
- [3188: Deprecated usage of binary fields whose length exceeds the platform maximum](doctrine#3188) thanks to @morozov
- [3192: Added more information to the deprecation notice](doctrine#3192) thanks to @morozov
- [3212: Deprecated usage of DB-generated UUIDs](doctrine#3212) thanks to @morozov

**New Features:**

**Bug Fixes:**

- [3149: Introduced binary binding type to support binary parameters on Oracle](doctrine#3149) thanks to @morozov
- [3178: Fix incorrect exception thrown from SQLAnywhere16Platform](doctrine#3178) thanks to @Majkl578
- [3044: Functional test for allowing dynamic intervals in date sub/add](doctrine#3044) thanks to @AshleyDawson
- [3049: Test failures caused by invalid database connection result in fatal error](doctrine#3049) thanks to @Majkl578

**Improvements:**

- [3033: Added support for available DSN parameters for the PDOSqlsrv driver](doctrine#3033) thanks to @aashmelev
- [3128: Add MySQL 8 reserved keywords](doctrine#3128) thanks to @mlocati
- [3143: initialize sql array into platform files](doctrine#3143) thanks to @AlessandroMinoccheri
- [3173: Fix composer branch aliases](doctrine#3173) thanks to @Majkl578
- [3157: When building a limit query, zero offset without a limit should be ignored](doctrine#3157) thanks to @morozov
- [3109: Allow to specify arbitrary SQL expression in AbstractPlatform::getDummySelectSQL()](doctrine#3109) thanks to @morozov
- [3141: allow creating PRIMARY KEY AUTOINCREMENT fields for sqlite (unit tests)](doctrine#3141) thanks to @TimoBakx
- [3180: Import simplified version of Common\Util\Debug for var dumping purposes](doctrine#3180) thanks to @Majkl578

**Documentation Improvements:**

- [3117: Added badges for the develop branch in README](doctrine#3117) thanks to @morozov
- [3125: Upgrading docs](doctrine#3125) thanks to @jwage
- [3144: added improvement type into pull request template](doctrine#3144) thanks to @AlessandroMinoccheri

**Code Quality Improvements:**

- [3025: Added PHPStan, apply changes for level 3](doctrine#3025) thanks to @Majkl578
- [3200: Php Inspections (EA Ultimate): minor code tweaks](doctrine#3200) thanks to @kalessil
- [3204: Fix typo in AbstractPlatform](doctrine#3204) thanks to @Majkl578
- [3205: Ignore OCI-* classes in static analysis (no stubs)](doctrine#3205) thanks to @Majkl578

**Continuous Integration Improvements:**

- [3102: Use newer PHPUnit to prevent crashes on failures](doctrine#3102) thanks to @Majkl578
- [3112: Removed hard-coded configuration filenames from the test runner](doctrine#3112) thanks to @morozov
- [3133: Travis DB2](doctrine#3133) thanks to @Majkl578, @morozov
- [3135: AppVeyor tweaks, retry coverage upload on failure](doctrine#3135) thanks to @Majkl578
- [3137: Workaround for the inability to use a post-PHPUnit script on ContinuousPHP](doctrine#3137) thanks to @morozov
- [3151: MSSQL DLL 5.2.0 has been released.](doctrine#3151) thanks to @photodude
- [3160: Test against Postgres 11](doctrine#3160) thanks to @Majkl578

**Dependencies**

- [3193: DBAL 2.8 needs Common 2.9](doctrine#3193) thanks to @Majkl578
- [3176: Eliminate dependency on doctrine/common](doctrine#3176) thanks to @Majkl578
- [3181: Remove dependency on doctrine/common](doctrine#3181) thanks to @Majkl578

# gpg: Signature made Fri Jul 13 06:02:10 2018
# gpg:                using RSA key 374EADAF543AE995
# gpg: Can't check signature: public key not found

# Conflicts:
#	.gitignore
#	README.md
#	lib/Doctrine/DBAL/Version.php
#	tests/appveyor/mssql.sql2008r2sp2.sqlsrv.appveyor.xml
#	tests/appveyor/mssql.sql2012sp1.sqlsrv.appveyor.xml
#	tests/appveyor/mssql.sql2017.pdo_sqlsrv.appveyor.xml
#	tests/appveyor/mssql.sql2017.sqlsrv.appveyor.xml
#	tests/travis/mariadb.mysqli.travis.xml
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 10, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants