-
Notifications
You must be signed in to change notification settings - Fork 2
Bump io.smallrye.reactive:mutiny from 2.9.4 to 3.0.0 in the mutiny group #103
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
Conversation
Bumps the mutiny group with 1 update: [io.smallrye.reactive:mutiny](https://github.com/smallrye/smallrye-mutiny). Updates `io.smallrye.reactive:mutiny` from 2.9.4 to 3.0.0 - [Release notes](https://github.com/smallrye/smallrye-mutiny/releases) - [Commits](smallrye/smallrye-mutiny@2.9.4...3.0.0) --- updated-dependencies: - dependency-name: io.smallrye.reactive:mutiny dependency-version: 3.0.0 dependency-type: direct:production update-type: version-update:semver-major dependency-group: mutiny ... Signed-off-by: dependabot[bot] <[email protected]>
fa6f0c8
to
7764782
Compare
} | ||
|
||
@Override | ||
default Id generate( |
Check notice
Code scanning / CodeQL
Confusing overloading of methods Note
generate
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 16 days ago
To resolve confusing overloading, the best approach is to give the methods clearer, more specialized names that convey their intended use and reduce ambiguity. Specifically:
- Rename
generate(ReactiveConnectionSupplier session, Object entity)
togenerateReactive(...)
. - Rename the "4-argument" variant's default implementation likewise to
generateReactive(...)
. - The methods overriding the super-interface (the synchronous versions) should keep their names and signatures for correct interface implementation, but should not create further ambiguity.
- In all implementations and references within this interface, update calls appropriately.
This avoids confusion without changing existing synchronous API contracts, and signals clearly to implementors and users which method is for which paradigm (reactive vs. blocking).
All changes are within hibernate-reactive-core/src/main/java/org/hibernate/reactive/id/ReactiveIdentifierGenerator.java
, inside the interface definition.
-
Copy modified line R40 -
Copy modified lines R42-R43
@@ -37,10 +37,10 @@ | ||
* | ||
* @param session the reactive session | ||
*/ | ||
CompletionStage<Id> generate(ReactiveConnectionSupplier session, Object entity); | ||
CompletionStage<Id> generateReactive(ReactiveConnectionSupplier session, Object entity); | ||
|
||
default CompletionStage<Id> generate(ReactiveConnectionSupplier session, Object owner, Object currentValue, EventType eventType) { | ||
return generate( session, owner ); | ||
default CompletionStage<Id> generateReactive(ReactiveConnectionSupplier session, Object owner, Object currentValue, EventType eventType) { | ||
return generateReactive( session, owner ); | ||
} | ||
|
||
@Override |
} | ||
|
||
@Override | ||
default Object generate(SharedSessionContractImplementor session, Object object){ |
Check notice
Code scanning / CodeQL
Confusing overloading of methods Note
generate
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 16 days ago
To fix the problem, avoid method overloading with two parameters of similar or potentially confusing types. In this case, rename the method generate(SharedSessionContractImplementor session, Object object)
(which overrides the superclass method) to a distinct name, for example, generateWithSharedSession
. However, since it is overriding an interface method from the Hibernate framework (IdentifierGenerator
), directly renaming may break the contract. Instead, the best fix (per the example recommendation) is to clarify the interface by providing distinct names for new methods introduced in this interface, so clients invoking reactive methods will clearly invoke the correct implementation.
The best course is to:
- Keep the overridden methods (with
@Override
) as required by the contract. - Rename the reactive-specific method to a new name, such as
generateReactive
, so that there's no confusion for users. - Fix all usages within this file so that
generate
reactive method is now named something distinct, and update the default methods accordingly.
All changes will be made in hibernate-reactive-core/src/main/java/org/hibernate/reactive/id/ReactiveIdentifierGenerator.java
. No additional imports are required. Only method names and their call sites will be updated.
-
Copy modified line R40 -
Copy modified lines R42-R43
@@ -37,10 +37,10 @@ | ||
* | ||
* @param session the reactive session | ||
*/ | ||
CompletionStage<Id> generate(ReactiveConnectionSupplier session, Object entity); | ||
CompletionStage<Id> generateReactive(ReactiveConnectionSupplier session, Object entity); | ||
|
||
default CompletionStage<Id> generate(ReactiveConnectionSupplier session, Object owner, Object currentValue, EventType eventType) { | ||
return generate( session, owner ); | ||
default CompletionStage<Id> generateReactive(ReactiveConnectionSupplier session, Object owner, Object currentValue, EventType eventType) { | ||
return generateReactive( session, owner ); | ||
} | ||
|
||
@Override |
this.uniqueKeyPropertyNames = uniqueKeyPropertyNames; | ||
uniqueKeyTypes = new Type[ uniqueKeyPropertyNames.length ]; | ||
for ( int i = 0; i < uniqueKeyPropertyNames.length; i++ ) { | ||
uniqueKeyTypes[i] = persister.getPropertyType( uniqueKeyPropertyNames[i] ); |
Check notice
Code scanning / CodeQL
Deprecated method or constructor invocation Note
EntityPersister.getPropertyType
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 16 days ago
To fix the problem, replace the usage of the deprecated persister.getPropertyType(String propertyName)
method with its recommended alternative.
For Hibernate 5.4+ and certainly Hibernate 6.x+, the alternative is to use the persister.getPropertyType(PropertyPath)
or the new metadata system, typically:
persister.getPropertyType(int propertyIndex)
- or for modern Hibernate:
persister.getPropertyMapping().getType(String propertyName)
(Hibernate 5.4+)- or fetch the
AttributeMapping
from the new runtime metamodel API, then call.getJdbcMapping().getJavaTypeDescriptor()
.
The simplest, backward- and forward-compatible replacement is to use:
persister.getPropertyMapping().getType(uniqueKeyPropertyNames[i])
This assumes that getPropertyMapping()
is available and returns something with a getType(String)
method, which is true for most versions of Hibernate since 5.x.
Changes to make:
- In the constructor, on line 47, change:
to
uniqueKeyTypes[i] = persister.getPropertyType( uniqueKeyPropertyNames[i] );
uniqueKeyTypes[i] = persister.getPropertyMapping().getType( uniqueKeyPropertyNames[i] );
- No changes to imports or other definitions are needed as
getPropertyMapping()
should already be available, and its return type exposesgetType(String)
, returning aType
. - No existing functionality is affected: the new code retrieves exactly the same information as the deprecated method but avoids deprecated API use.
-
Copy modified line R47
@@ -44,7 +44,7 @@ | ||
this.uniqueKeyPropertyNames = uniqueKeyPropertyNames; | ||
uniqueKeyTypes = new Type[ uniqueKeyPropertyNames.length ]; | ||
for ( int i = 0; i < uniqueKeyPropertyNames.length; i++ ) { | ||
uniqueKeyTypes[i] = persister.getPropertyType( uniqueKeyPropertyNames[i] ); | ||
uniqueKeyTypes[i] = persister.getPropertyMapping().getType( uniqueKeyPropertyNames[i] ); | ||
} | ||
} | ||
|
Looks like io.smallrye.reactive:mutiny is no longer updatable, so this is no longer needed. |
Bumps the mutiny group with 1 update: io.smallrye.reactive:mutiny.
Updates
io.smallrye.reactive:mutiny
from 2.9.4 to 3.0.0Release notes
Sourced from io.smallrye.reactive:mutiny's releases.
... (truncated)
Commits
c5fcd0a
chore(release): update version metadata for Mutiny 3.0.0da75a78
Merge pull request #1956 from jponge/misc/cleanups-pre-3.0.067fe9de
style: misc code polishing edits8168cbb
Merge pull request #1955 from smallrye/dependabot/maven/org.apache.maven.plug...c195471
Merge pull request #1954 from smallrye/dependabot/maven/version.surefire.plug...2adb822
Merge pull request #1953 from smallrye/dependabot/maven/io.smallrye-jandex-ma...6499b27
build(deps): bump org.apache.maven.plugins:maven-shade-plugin92bd147
build(deps): bump version.surefire.plugin from 3.2.5 to 3.5.45d65673
build(deps): bump io.smallrye:jandex-maven-plugin from 3.4.0 to 3.5.0b282f42
Merge pull request #1848 from hadadil/makeOnFailureToBeTypedDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase
.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebase
will rebase this PR@dependabot recreate
will recreate this PR, overwriting any edits that have been made to it@dependabot merge
will merge this PR after your CI passes on it@dependabot squash and merge
will squash and merge this PR after your CI passes on it@dependabot cancel merge
will cancel a previously requested merge and block automerging@dependabot reopen
will reopen this PR if it is closed@dependabot close
will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditions
will show all of the ignore conditions of the specified dependency@dependabot ignore <dependency name> major version
will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor version
will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>
will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>
will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>
will remove the ignore condition of the specified dependency and ignore conditions