Enable UUID 1.0

[marti4d]

PR Info

• Closes Enable UUID v1.0 for Postgres #325

Adds

• Support for Uuid v1.0

Breaking Changes

• Any downstream project will need to change uuid dependency to ^1, or change their code to use uuid_0() and such everywhere. Very likely we need a breaking-change version increase

[tyt2y3]

Thank you. I think it looks good.

[tyt2y3]

May be we shall release that in 0.26

[jdrouet]

So this means we can have both uuid@1 and uuid@0.8 enabled? 🤔

[jdrouet]

I proposed this PR not to have this behavior and keep uuid as a single and unique dependency.

[marti4d]

Ah -- Your PR is very similar to my original change when I first proposed my PR. The issue I ran into -- and you will see this when you remove the "draft" keyword and pre-commit testing is done -- is that you've now created mutually-exclusive features (cargo docs about this)

But we run all our tests with cargo test --all-features, and so you will see errors when that is run.

I had already suggested instead that we should have a "pecking order", where if UUID-1 is enabled it will automatically upstage UUID-0. I remember the issue being that sprinkling these conditional blocks everywhere gets kind-of nasty:

#[cfg(all(not(feature = "with-uuid-1"), feature = "with-uuid-0"))]
use uuid_0::Uuid as Uuid;

#[cfg(feature = "with-uuid-1")]
use uuid_1::Uuid as Uuid;

#[cfg(any(feature = "with-uuid-1", feature = "with-uuid-0"))]
// Do thing with Uuid

That being said, maybe now that @tyt2y3 has seen my PR and the juggling that has to be done to enable both at the same time, they may prefer that. But I think at-least you'll have to add a few more conditionals to implement this upstaging-behavior.

[jdrouet]

I ran into this problem when trying to upgrade time in this PR and I'm trying to find a way to fix the CI.

[ikrivosheev]

@jdrouet I think you dont need to fix CI. I think is better fix code.

[jdrouet]

@ikrivosheev do you think we should be able to have uuid@0.8 and uuid@1 at the same time?

For the time related PR, I'm still working on it 😉

[ikrivosheev]

On one hand: CI on the other hand - very strange behavior when we compile one library with a different version...

I think it is better to panic when both features are enabled.

[tyt2y3]

Um... actually I have a worse idea. Maintaining multiple major versions in the same library seems not to be so scalable. After a some thought, I think we should ONLY support the latest major release of a library.
At the same time, I would suggest we also maintain the one previous release of sea-query. For example, let's say we upgrade uuid to 1 in 0.26 and drop uuid 0. In the meantime, we shall still backport features / fixes to sea-query 0.25 to ease the transition.