Почему тип этих объектов свойств пользователя: адреса, электронные письма, организации и т. д.?

Я имею в виду тип Google.Apis.Admin.Directory.directory_v1.Data.User.

Тип свойства Addresses, например, в бета-версиях (т.е. 1.7 и старше) был

public virtual System.Collections.Generic.IList<UserAddress> Addresses { get; set; }

В более поздних версиях (в настоящее время 1.9.1) , все они имеют тип объекта.

public virtual object Addresses { get; set; }

Каковы причины изменений и сценариев использования?

Я просмотрел примечания к выпуску, Интернет, группа Google, SO и т. д. и не нашел объяснений по этому поводу.


google-admin-sdk google-api-dotnet-client google-directory-api
person Duoc Tran    schedule 14.04.2015    source источник
comment
Можно еще добавить ревизию API в обоих случаях, похоже API поменяли (а не основную клиентскую библиотеку). Итак, я спрашиваю, что такое xxx и yyy (1.7.0.xxx и 1.9.1.yyy)?   -  person peleyal    schedule 14.04.2015
comment
Версии 1.7 и 1.9, упомянутые в вопросе, — это 1.7.0.25-beta и 1.9.0.53. Насколько я знаю, изменение впервые появилось в ревизии 1.8.1.350.   -  person Duoc Tran    schedule 15.04.2015
comment
@peleyal Я заметил, что документ с представлением ресурсов показывает 2 addresses поля , один доступен для записи, другой нет. Доступное для записи — это массив объектов, тогда как поле addresses только для чтения — это строка. Я получаю массив объектов при тестировании в API Проводник. То же самое для emails, phones и т. д.   -  person Duoc Tran    schedule 20.04.2015
comment
Как видно из Developers.google.com/apis-explorer/#s/discovery/v1/ свойство address в пользовательском объекте определяется как любое (а не массив объекта)   -  person peleyal    schedule 20.04.2015

Ответы (1)


arrow_upward
1
arrow_downward

Изменение в бэкенде привело к непреднамеренным последствиям изменения документа обнаружения для службы, в результате чего поле адресов (и другие) было помечено как type=any. Это вызывает проблемы для языков со строгим типом, таких как .NET, как вы обнаружили. Команда знает о проблеме, но неясно, когда будет доступно исправление.

person Eric Koleda    schedule 20.05.2015
comment
Спасибо, @Eric Koleda, за объяснение. Я обошел это, десериализовав его в соответствующий тип, т.е. Emails в List<UserEmail>, если он имеет тип Newtonsoft.Json.Linq.JArray. - person Duoc Tran; 22.05.2015
comment
@DuocTran, не могли бы вы поделиться кодом десериализации, который вы используете? Вместо пакета NuGet я использовал копию исходного кода клиента C# из https://developers.google.com/admin-sdk/directory/v1/libraries изменены таким образом, чтобы свойства Addresses, Emails, ExternalIds, Ims, Organizations, Phones, Relations и Websites имели соответствующие IList<T> type, но я хотел бы вернуться к использованию пакета NuGet, если это возможно. - person Sean Rose; 29.04.2016
comment
@EricKoleda, у вас есть какие-либо обновления, чтобы поделиться, если / когда это может быть исправлено? Я обнаружил две проблемы, связанные с этим, хотя обе относятся к клиенту Java, и ни одна из них не видела каких-либо существенных обновлений: Проблема 3645: Неверный генератор кода для Directory API в Java-клиенте: в пользовательском классе отсутствуют явные типы. Проблема 3730: последняя версия клиента Directory API возвращает Object вместо правильного класса. - person Sean Rose; 29.04.2016
comment
К сожалению, у меня нет никаких обновлений, чтобы сообщить. Пока ситуация остается неидеальной. - person Eric Koleda; 02.05.2016
comment
@SeanRose это обходной путь, а не идеальное решение. Я проверяю свойства и десериализую их. Возможно, вы захотите создать методы расширения, чтобы упростить код. if (user.Emails != null && user.Emails.GetType() == typeof(Newtonsoft.Json.Linq.JArray)) { var emails = Newtonsoft.Json.JsonConvert.DeserializeObject<List<Google.Apis.Admin.Directory.directory_v1.Data.UserEmail>>(user.Emails.ToString()); } - person Duoc Tran; 03.05.2016
comment
Спасибо @DuocTran. В итоге я фактически перезаписал соответствующее свойство десериализованным типом каждый раз, когда я получаю пользователя из API, и клиент по-прежнему правильно сериализует его для добавления/обновления. Например: var externalIdsJson = user.ExternalIds as Newtonsoft.Json.Linq.JToken; if (externalIdsJson != null) { user.ExternalIds = externalIdsJson.ToObject<IList<Google.Apis.Admin.Directory.d‌​irectory_v1.Data.UserExternalId>>(); } Это по-прежнему требует приведения свойства к правильному типу каждый раз, когда я его использую, но избавляет от необходимости синхронизировать отдельную копию списка с оригиналом. - person Sean Rose; 06.05.2016