From b6a7b6d40b4258de5fe4463e899b8f73747ab3dc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Wojciech=20Przytu=C5=82a?= <wojciech.przytula@scylladb.com>
Date: Wed, 13 Nov 2024 10:40:51 +0100
Subject: [PATCH] book: update examples to use DeserializeValue

Also, no longer mention the limitations of old derive macros.
The new macros have no limitations compared to Serialize macros.
---
 docs/source/data-types/udt.md                      | 9 +++++----
 docs/source/migration-guides/0.11-serialization.md | 2 --
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/docs/source/data-types/udt.md b/docs/source/data-types/udt.md
index 4a8f91b137..ddafb748e9 100644
--- a/docs/source/data-types/udt.md
+++ b/docs/source/data-types/udt.md
@@ -20,13 +20,14 @@ and `DeserializeValue` macros documentation.
 ```rust
 # extern crate scylla;
 # async fn check_only_compiles() {
-use scylla::macros::{FromUserType, SerializeValue};
+use scylla::macros::{DeserializeValue, SerializeValue};
 
 // Define a custom struct that matches the User Defined Type created earlier.
-// Fields must be in the same order as they are in the database and also
-// have the same names.
+// Fields don't have to be in the same order as they are in the database.
+// By default, they must have the same names, but this can be worked around
+// using `#[rename] field attribute.
 // Wrapping a field in Option will gracefully handle null field values.
-#[derive(Debug, FromUserType, SerializeValue)]
+#[derive(Debug, DeserializeValue, SerializeValue)]
 struct MyType {
     int_val: i32,
     text_val: Option<String>,
diff --git a/docs/source/migration-guides/0.11-serialization.md b/docs/source/migration-guides/0.11-serialization.md
index 77004b03de..601be0da2e 100644
--- a/docs/source/migration-guides/0.11-serialization.md
+++ b/docs/source/migration-guides/0.11-serialization.md
@@ -42,8 +42,6 @@ The driver comes a set of `impl`s of those traits which allow to represent any C
 
 By default, the `SerializeRow` and `SerializeValue` **will match the fields in the Rust struct by name to bind marker names** (in case of `SerializeRow`) **or UDT field names** (in case of `SerializeValue`). This is different from the old `ValueList` and `IntoUserType` macros which did not look at the field names at all and would expect the user to order the fields correctly. While the new behavior is much more ergonomic, you might have reasons not to use it.
 
-> **NOTE:**  The deserialization macro counterparts `FromRow` and `FromUserType` have the same limitation as the old serialization macros - they require struct fields to be properly ordered. While a similar rework is planned for the deserialization traits in a future release, for the time being it might not be worth keeping the column names in sync with the database.
-
 In order to bring the old behavior to the new macros (the only difference being type checking which cannot be disabled right now) you can configure it using attributes, as shown in the snippet below:
 
 ```rust