Changeset with the field date is lost in some edge cases

BC Break Report

Q
A

BC Break
yes

Version
2.1

Summary
When we have a field with the type date if the field is updated in less than 1 second the update does not work correctly. The field is not updated
Previous behavior
In this previous version when the field was a date we compared 2 MongoDate
https://github.com/doctrine/mongodb-odm/blob/1.3.x/lib/Doctrine/ODM/MongoDB/UnitOfWork.php#L816-L823
In the MongoDate object we have a timestamp and the miliseconds.
In the new version we have https://github.com/doctrine/mongodb-odm/blob/2.6.x/lib/Doctrine/ODM/MongoDB/UnitOfWork.php#L798-L809
The UTCDateTime object contains also the milliseconds but we loose this information in the changeSet.
Is-it possible to only cast the UTCDateTime in string in order to keep this information ?
The code should be
                // skip equivalent date values
                if (isset($class->fieldMappings[$propName]['type']) && $class->fieldMappings[$propName]['type'] === 'date') {
                    /** @var DateType $dateType */
                    $dateType      = Type::getType('date');
                    $dbOrgValue    = $dateType->convertToDatabaseValue($orgValue);
                    $dbActualValue = $dateType->convertToDatabaseValue($actualValue);

                    $orgMillisec    = $dbOrgValue instanceof UTCDateTime ? (string) $dbOrgValue : null;
                    $actualMillsec = $dbActualValue instanceof UTCDateTime ? (string) $dbActualValue : null;

                    if ($orgMillisec === $actualMillsec) {
                        continue;
                    }
                }

According to docs casting to string will not be enough as it'll get us timestamp again.
@alcaeus do you remember the reason why we're casting values to anything instead of relying on `$dbOrgValue == $dbActualValue ?

@alcaeus do you remember the reason why we're casting values to anything instead of relying on $dbOrgValue == $dbActualValue?

Off the top of my head, no.

The code should be [...]

While casting to string will indeed give us a string with millisecond precision, this shouldn't be necessary and comparing the UTCDateTime instances directly is the way to go as the class implements a compare handler. @olivier34000 if you'd like, you can create a PR (ideally with a failing test case) to change this. No need to cast to milliseconds, just comparing $dbOrgValue == $dbActualValue should be sufficient. Just keep in mind to use a loose comparison, as a strict comparison (===) will always return false as the variables don't contain the same object instance.


Fix: ssh - Allow keys to sudo user folder

Fix #715 issue
@wlln please check if it is ok for you 😊
Once merged, 1.6 release.

Dear @oxedions
Apart from the point @strus38 and @neilmunday suggest, I'm fine with this PR.

Thanks a lot for the review ! You are right, my bad. Let me fix that 😊


Feature-based deployment

This issue includes the configuration of glbinding, more specifically it's generation step, to only include one or several features of OpenGL.

While implementing this, other variation points in the generation can also be made available as cmake option or command line parameters of the generation script (e.g., integrating documentation #18 or transposing the gl directory #83).

As our code generation just moved to https://github.com/cginternals/khrbinding-generator, I suggest to handle the issue there.


Merge branch 'main' into smithy-rs-release-0.55.x

This tree is the result of:
git clone https://github.com/awslabs/smithy-rs.git
git checkout -b davidpz/smithy-rs-release-0.55.x origin/smithy-rs-release-0.55.x
git merge --strategy-option theirs origin/main

Upon which 3 conflicts arise because files were deleted and --strategy-option theirs does not make Git use whatever was done in main.
Unmerged paths:
  (use "git add/rm <file>..." as appropriate to mark resolution)
        both added:      aws/sra-test/integration-tests/aws-sdk-s3/tests/interceptors.rs
        deleted by them: codegen-server-test/python/model/pokemon.smithy
        both added:      rust-runtime/aws-smithy-runtime-api/src/client/runtime_plugin.rs

Which I resolved with:
git add aws/sra-test/integration-tests/aws-sdk-s3/tests/interceptors.rs
git add rust-runtime/aws-smithy-runtime-api/src/client/runtime_plugin.rs
git rm codegen-server-test/python/model/pokemon.smithy

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

That didn't work. Seems like the merge took changes from both trees in RuntimeType.kt where there were no conflicts, instead of applying the changes in theirs.


[FEATURE] Auto bump provider references

Affected project(s)

[X] documentation
[X] examples
[ ] wasmCloud host
[ ] wasmCloud CLI (wash)
[ ] wasmCloud dashboard UI (washboard)
[ ] capability providers
[ ] provider bindgen
[ ] control interface client
[ ] other / not sure

Is your feature request related to a problem? Please describe.
No response
Describe the solution you'd like
It would be really nice if we didn't have to manually bump all of our examples to their latest provider versions. See #2336 for example
Describe alternatives you've considered
No response
Additional context
No response

Not stale, it would still be nice if we had a way to do this!

If you do not mind a +1 tool in your repository; renovate is capable of this. With a regex in given files it should be able to identify newer OCI images like this https://docs.renovatebot.com/modules/manager/regex/#configuration-templates 🤔 You can assign it to me I'll can give it a try.

Hey @markkovari thanks for noting that -- this is definitely something we want that people just didn't have the know-how (of renovate, evidently!) to do quickly without writing a script or something. Please take a shot at it!


chore: enable Fedora 41 builds

Thank you for contributing to the Universal Blue project!
Please read the Contributor's Guide before submitting a pull request.

@p5
common build failures:

xpadneo ... it's not yet available for F41. We could conditionally not build that as a temporarly workaround.

extra build failures:

zenergy fails on kernel 6.11.1 ... i'm not sure why

nvidia build failures:

looks like the F41 rpmbuild issue with @m2Giles has addressed elsewhere... can you take a look? https://github.com/ublue-os/akmods/actions/runs/11205646915/job/31145409774#step:12:1580

For the nvidia issues, we need to do the same as what we did in kernel-cache. Add a symlink and specify the symlink as the build-root.
https://github.com/ublue-os/kernel-cache/blob/a768ce0a789a638f05746dcad46735197597735b/fetch.sh#L157
https://github.com/ublue-os/kernel-cache/blob/a768ce0a789a638f05746dcad46735197597735b/fetch.sh#L170

For the nvidia issues, we need to do the same as what we did in kernel-cache. Add a symlink and specify the symlink as the build-root.
https://github.com/ublue-os/kernel-cache/blob/a768ce0a789a638f05746dcad46735197597735b/fetch.sh#L157
https://github.com/ublue-os/kernel-cache/blob/a768ce0a789a638f05746dcad46735197597735b/fetch.sh#L170

I can do this, thank you .

I just did it.

I just did it.

even better! thank you!

Looks like nvidia is now working for F41.
We are only caching kernels for asus and main right now. There is no F41 of surface, fsync, and coreos yet.

Not sure why evdi doesn't have the kmod in repo yet at least that's what the error looks like.

Not sure why evdi doesn't have the kmod in repo yet at least that's what the error looks like.

It's there, but I noticed something similar to this in bluefin when I was converting to support negativo17... sometimes the package providing the "foo-kmod-common" doesn't resolve properly. Thus in bluefin we now specify an extra package with the kmod install.
I think we need to do the same here

@p5 @m2Giles @KyleGospo
I think this is probably ready for review to at least start building F41 akmods images.
Caveats are 4 kmods not building yet and those are documented in #248


fix!: export instrumentations only as named export

This PR is targets how we name and export instrumentation classes from our packages across the repo, and introduces consistency and best practices to align the code base.
It makes it so that:

each instrumentation class has the same name as the name it is exported with (few were called Instrumentation instead of FooInstrumentation)
align the index.ts file to export consistently - everything from instrumentation.ts and type.ts. This is to remove complexity and promote safe practices. This aligns the few places which were too complex, to an equivalent import and export statements to align with most packages in the repo.
Remove the default export of the instrumentation class from the few places where it was present. since all instrumentations supports named exports of the class, I assume very few people if any are actually importing an instrumentation this way, but it is possible however, and those users will have their transplation broken when upgrading to the new version and will need to update the import.

Benefits

Consistency across the various packages in the repo - better maintenance and developing experince.
Shorter code - remove some of the un-needed complexities in the index.ts files and replace with shorter equivalents.
better practices - the types.ts and instrumentation.ts files are intended to be user facing, and only export what the user is expected to consume. More on that in the GUIDELINES. Exporting everything from those files will prevent accidentally forgetting to add new types to the index.ts as happen in the past

Breaking Change
This PR is a breaking change by removing the default export for the following instrumentations:

fs
lru-memoizer
tedious
generic-pool
knex
memcahed
mysql2
restify
router

As state above, it is possible breaking change, but very unlikely for real users as this style is supported for only few instrumentations. It will be published as minor patch which should not be pulled automatically by users that has caret dependency, so they need to actively pull new version and will observe the transpilation failing.

Thanks for taking care of this. :slightly_smiling_face:
As far as aligning export goes, I wonder if we should actually align them to be explicit exports (instead of wildcard exports) wherever possible. It has happened often that we accidentally add to the public interface by adding something to a file which in index.ts was then re-exported by a wildcard export.
We can avoid these accidental exports by using explicit exports wherever we can (see also: https://github.com/open-telemetry/opentelemetry-js/issues/4186)

Thanks for taking care of this. 🙂
As far as aligning export goes, I wonder if we should actually align them to be explicit exports (instead of wildcard exports) wherever possible. It has happened often that we accidentally add to the public interface by adding something to a file which in index.ts was then re-exported by a wildcard export.
We can avoid these accidental exports by using explicit exports wherever we can (see also: open-telemetry/opentelemetry-js#4186)

Thank you for the review
This issue has a bit of history behind it:

up until #1251 , the types.ts files contained both public facing exports, and internal exports.
one can potentially mix public and private exports into the same file, and apply explicit exports from index.ts as suggested
private types often rely on importing dev dependency, like the instrumented package.
if an import from dev dependency is found in a .d.ts file, it will fail transpilation for the instrumentation package users. which happened very often in the past.
types.ts and instrumentation.ts both contains user facing exports, thus the user transpiler will for sure need to import both types.d.ts and index.d.ts and all there transitive dependencies
It was agreed that both these files MUST NOT contain any private exports, due to how easy it is for dev dependencies to leak into the public api with private exports, even with explicit exports.
Given the last comment, if all exports from types.ts and instrumentation.ts are public, then exporting them as wildcard is safe.
using explicit exports can makes it easier to forget exporting a type, which has happened frequently in the past.

All these decisions where made to prevent painful issues which had happen. I am open to discuss alternatives but personally think that using wildcard exports is the safest option, which also communicate the intent of these files to code readers / future maintainers, and reduces the chance of forgetting to export something important or exporting dev dependencies in the public api.