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

Can't compile Catalytic 0.1.20 version with scylla_macros 0.2.2 #43

Closed
guvenir18 opened this issue Dec 21, 2023 · 8 comments
Closed

Can't compile Catalytic 0.1.20 version with scylla_macros 0.2.2 #43

guvenir18 opened this issue Dec 21, 2023 · 8 comments

Comments

@guvenir18
Copy link

Hello, thank you for this great crate.

My issue is suddenly, I can't compile this crate, I get this error:

failed to resolve: could not find LegacySerializedValues in _macro_internal
--> ../.cargo/registry/src/index.crates.io-6f17d22bba15001f/catalytic-0.1.20/src/table_metadata.rs:34:17
|
34 | #[derive(Debug, scylla::ValueList, scylla::FromRow)]
| ^^^^^^^^^^^^^^^^^
| |
| could not find LegacySerializedValues in _macro_internal
| help: a struct with a similar name exists: SerializedValues
|
= note: this error originates in the derive macro scylla::ValueList (in Nightly builds, run with -Z macro-backtrace for more info)

Problem might be related to scylla_macros crate. I could compile until yesterday. I compared Cargo.lock files and only difference was scylla_macros crate version is now 0.2.2, which was 0.2.1 until yesterday. 0.2.2 version came yesterday.

@Jasperav
Copy link
Owner

Hey @guvenir18, thanks for your compliment.

The scylla rust driver has been updated this week to a new version with breaking changes. I want to update this crate asap but I am blocked by scylladb/scylla-rust-driver#890.

@guvenir18
Copy link
Author

@Jasperav Thank you for your quick response, we will wait for them then.

I also want to ask another question which is not related to this issue. I want to modify Transformer so it maps TIMESTAMP values into i64 type, not scylla::frame::value::Timestamp. Is this possible ?

@Jasperav
Copy link
Owner

I see that there is no way of converting types sadly... what about changing the timestamp type to a bigint? Thats how I did it, works fine if you only store milliseconds and not date related stuff like timezones

@guvenir18
Copy link
Author

Thank you for quick answer, that is probably best solution. I know I asked a lot but one last question.

I am trying to write a query using "query!" macro which is "select token(user_id) from users where user_id = ?". This query normally works, I am working on implementing your crate on existing project. I get an error, saying "illegal column: token(user_id)" error. Does this macro works with token function or am I doing something wrong?

@Jasperav
Copy link
Owner

Oh you can ask anything :) Hmm no the token method does not work yet. I read about it here and the return_type can be dynamic? https://opensource.docs.scylladb.com/stable/cql/functions.html Maybe I can make something easy so that it always returns a i64, does that sound good?

@guvenir18
Copy link
Author

I am new to Rust and database stuff so I am still learning, thanks for your help :) i64 type would be enough for my case.

@piodul
Copy link

piodul commented Dec 21, 2023

@guvenir18 The issue you described here is our (ScyllaDB rust driver team) fault, we accidentally released a semver-incompatible change in 0.2.2. Catalytic 0.1.20 should we usable with the driver in version 0.10 but we broke that - sorry, we will fix that soon.

For the time being, you should downgrade the scylla-macros dependency in your lockfile - the following command should work:

cargo update -p scylla-macros --precise 0.2.1

@Lorak-mmk
Copy link

Lorak-mmk commented Dec 21, 2023

This should now be fixed - scylla-macros 0.2.2 was yanked, and re-released as 0.3.0
0.2.1, used by scylla 0.10, was released again as 0.2.3.
So now a cargo update should fix this problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants