getattr ? Есть обьект структура которого создается в рантайме из описания в json и хочется иметь доступ к полям обьекта просто через точку - типа o.field (имя которое после точки во время компиляции неизвестно). С какой стороны заходить?
Нет.
В общем случае, нет. Самое близкое -- serde_json::Value, но это далеко не так эргономично как ты хочешь. Для неизвестных схем удобных решений нет. Для частично известных -- смотри в сторону serde-query
А ты уверен что схему нельзя статически задать?
Наделай методов объекту по типу .field() и будет почти то же самое, только две скобочки ещё
уверен, она реально меняется иногда. Это модель описания сети. Host имеет аттрибуты name, hardwareType и тд. В какой-то момент это число атрибутов меняется - могут добавить что-нибудь. Мне нужно сделать либу что-бы с этим было удобно работать
Зачем плохому новичков учишь :\ Ну можно возвращать Option<&T> и будет норм, да.
удалятся поля могут?
теортетически да
ИМХО, задать схему статически и обновлять при необходимости удобнее чем жонглировать динамическим Value
а есть набор полей, которые никогда не будут удаляться\изменяться?
Что ты намерен делать если нужное поле удалилось?
Возможность есть, через макросы. Аналогично тому, как это сделано в sqlx https://github.com/launchbadge/sqlx/blob/master/src/macros.rs Позволяет писать async fn list_todos(pool: &MySqlPool) -> anyhow::Result<()> { let recs = sqlx::query!( r#" SELECT id, description, done FROM todos ORDER BY id "# ) .fetch_all(pool) .await?; // NOTE: Booleans in MySQL are stored as `TINYINT(1)` / `i8` // 0 = false, non-0 = true for rec in recs { println!( "- [{}] {}: {}", if rec.done != 0 { "x" } else { " " }, rec.id, &rec.description, ); } Ok(()) } вот эти rec.id, rec.description и rec.done определяются из схемы базы данных на этапе билда. Там же проверяется наличие этих полей в рекордсете, который генерирует SQL запрос выше. Реализация конечно жесть, но теоретически возможность есть.
+. В обоих случаях кот менять придётся
но не код библиотеки
я бы у структуры задал явно те поля, которые никогда не будут удаляться остальное клал бы в какую-нибудь хешмапу (поле экстра), у которой значения хранить как стринги
Я бы Apache avro внедрил бы с обоих сторон)) так, холиварить нельзя в этом чате
Тормозной avro, как всегда присутствует трейдофф "гибкость -vs- производительность". Avro решили выбрать один конец, иногда это оправдано.
Компактный, можно поля удалять в отличии от... альтернатив. Растовой реализации не видел, кстати.
Обсуждают сегодня