Aws-lambda-dotnet: Amazon.Lambda.Serialization.SystemTextJson.LambdaJsonSerializer يستخدم غلاف خاصية مختلف عن Amazon.Lambda.Serialization.Json.JsonSerializer

تم إنشاؤها على ١٥ أبريل ٢٠٢٠ · 43تعليقات · مصدر: aws/aws-lambda-dotnet

يبدو أن سلوك الغلاف الافتراضي قد تغير بين Amazon.Lambda.Serialization.Json.JsonSerializer و Amazon.Lambda.Serialization.SystemTextJson.LambdaJsonSerializer .

إليك بعض نماذج التعليمات البرمجية لاختبار الفرق:

// create an instance to serialize
var record = new Record {
    Foo = "Hello world!"
};

// show serialization with original Lambda serializer based on Newtonsoft.Json
var oldSerializer = SerializeWith(record, new Amazon.Lambda.Serialization.Json.JsonSerializer());
Console.WriteLine($"Amazon.Lambda.Serialization.Json.JsonSerializer: {oldSerializer}");

// show serialization with new Lambda serializer based on System.Text.Json
var newSerializer = SerializeWith(record, new Amazon.Lambda.Serialization.SystemTextJson.LambdaJsonSerializer());
Console.WriteLine($"Amazon.Lambda.Serialization.SystemTextJson.LambdaJsonSerializer: {newSerializer}");

// show serialization with System.Json.Text
var jsonTextSerializer = System.Text.Json.JsonSerializer.Serialize<Record>(record);
Console.WriteLine($"System.Text.Json.JsonSerializer: {jsonTextSerializer}");

// local functions
string SerializeWith<T>(T value, Amazon.Lambda.Core.ILambdaSerializer serializer) {
    using var buffer = new MemoryStream();
    serializer.Serialize<T>(value, buffer);;
    return System.Text.Encoding.UTF8.GetString(buffer.ToArray());
}

ينتج الكود أعلاه الناتج التالي:

Amazon.Lambda.Serialization.Json.JsonSerializer: {"Foo":"Hello world!"}
Amazon.Lambda.Serialization.SystemTextJson.LambdaJsonSerializer: {"foo":"Hello world!"}
System.Text.Json.JsonSerializer: {"Foo":"Hello world!"}

bug

مصدر

bjorg

التعليق الأكثر فائدة

هل من الممكن إبقاء هذه القضية في الموضوع؟

Kralizek في ٢٤ أبريل ٢٠٢٠

👍3

ال 43 كومينتر

متفق عليه لم يكن يجب أن أقوم بتبديل الغلاف بين المكتبتين. أعتقد أننا نفتقر إلى اختبارات الطلبات والردود المخصصة لأن الاختبارات الآن تركز في الغالب على أحداث AWS.

الآن بعد أن تم تغيير السلوك الافتراضي هذا أمر غير ممكن حقًا. اقتراحي هو إضافة مُنشئ جديد يأخذ تعدادًا لنمط الغلاف حتى تتمكن من إعلان الغلاف الذي تريد استخدامه. يمكنني بعد ذلك تحديث القوالب لاستخدام المُنشئ الجديد. ما هو شعورك حيال هذا العمل؟

normj في ١٥ أبريل ٢٠٢٠

👎1

لا أعرف ما هي الفكرة هنا. أتفهم أنك لا تريد كسر الأشخاص الذين قد يكون لديهم تبعية. يبدو أن الخطأ كان الاعتقاد بأن AWS لديها اتساق في تسمية حقول JSON (أي AWSNamingPolicy ). لم يحدث ذلك. تستخدم بعض الخدمات غلاف Pascal ، مثل CloudFormation:
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/crpg-ref-responses.html

تغيير الغلاف تلقائيًا وعدم احترام السلوك الافتراضي System.Text.Json هو عيب فادح ، IMHO. ربما تفكر في تحرير Amazon.Lambda.Serialization.SystemTextJson.LambdaJsonSerializerV2 ووضع القديم على الجليد.

bjorg في ١٥ أبريل ٢٠٢٠

👍1

للتوضيح ، بما أنني لست على دراية بكيفية عمل ذلك ، فإن إعلان سمة التجميع يُستخدم فقط لإلغاء التسلسل ، أليس كذلك؟

[assembly: LambdaSerializer(typeof(Amazon.Lambda.SystemTextJson.LambdaJsonSerializer))]

ومع ذلك ، هل هناك حاجة حتى إذا استخدمت توقيع المعالج هذا؟

Task<Stream> FunctionHandlerAsync(Stream stream, ILambdaContext context)

ماذا يحدث إذا لم يكن هناك تصريح LambdaSerializerAttribute للتجميع أو طريقة نقطة الدخول؟

bjorg في ١٥ أبريل ٢٠٢٠

normj قد يكون أحد الخيارات هو إضافة سمات لتسمية خصائص json بشكل صريح وبالتالي احترام التسمية بغض النظر عن الغلاف

3GDXC في ١٦ أبريل ٢٠٢٠

👍1

أوافق على هذا الاقتراح - إنه عمل شاق لمرة واحدة لإضافتهم ، لكنهم دائمًا على صواب.

martincostello في ١٦ أبريل ٢٠٢٠

normj IMHO هذه مشكلة تنفيذية تحتاج / يجب معالجتها على المدى الطويل باعتبارها خطأً لأن هذا تغيير غير مقصود

3GDXC في ١٦ أبريل ٢٠٢٠

@ 3GDXC أوافق على أنه خطأ في التنفيذ. مجرد التفكير في الحل. لدينا حاليًا في الحزمة جهاز تسلسلي واحد يسمى LambdaJsonSerializer . ماذا لو أضفنا المتسلسل PascalCaseLambdaJsonSerializer و CamelCaseLambdaJsonSerializer والذي يمتد من LambdaJsonSerializer . يمكنني تغيير القوالب لاستخدام PascalCaseLambdaJsonSerializer للحفاظ على السلوك الحالي. إنها نوع من نسخة أكثر وضوحًا من اقتراح bjorg لوجود LambdaJsonSerializerV2.

normj في ١٦ أبريل ٢٠٢٠

normj IMHO سيكون من الأفضل تجنب الالتباس لإضافة سمات JsonPropertyName إلى الرسائل بحيث بغض النظر عن تكوين / خيارات المتسلسل ، فإن Json الناتج يلتزم بتسمية السمة.

أفهم تمامًا سبب إحجامك عن إدخال تغيير مفاجئ آخر (مع التصحيح) في غضون أيام من إصدار دعم .NET 3.1 ؛ وإذا كان لدينا (ملكيًا) عددًا من مشكلات UP-FOR-GRABS ، فلا اختبار للوحدة / الانحدار يمكن للمجتمع أن يساعد في جعل التنفيذ يتطور ويختبر قبل الإصدار.

يسعدني تقديم المساعدة إذا / عند الحاجة فقط قل الكلمة.

عمل رائع حتى الآن ، أحب رؤية دعم aws lamba و. net الأساسي ينمو

3GDXC في ١٦ أبريل ٢٠٢٠

@ 3GDXC ضع في اعتبارك أن الغلاف يؤثر فقط على الكائنات https://github.com/aws/aws-lambda-dotnet/blob/master/Libraries/src/Amazon.Lambda.APIGatewayEvents/APIGatewayProxyResponse. CS # L18

تكمن المشكلة في كائنات الاستجابة التي ينشئها الآخرون حيث لا أتحكم فيما إذا كانوا يستخدمون خاصية JsonPropertyName أم لا.

normj في ١٦ أبريل ٢٠٢٠

normj نقطة جيدة ؛ قد يكون الاستشاري يجب أن يتضمن دائمًا سمات JsonPropertyName لفرض تسمية صريحة لممتلكاتك و / أو عقود البيانات (أفضل الممارسات)

3GDXC في ١٦ أبريل ٢٠٢٠

normj قد يكون البديل هو تجريد JsonSerializerOptions بعيدًا في فئة LambdaSerializerOptions وإضافة الخيارات كمعامل مُنشئ في السمة حتى يكون للمسلسل خيارات مخصصة يمكن للمطور تجاوزها على مستوى التجميع / الأسلوب

3GDXC في ١٦ أبريل ٢٠٢٠

ماذا عن وضع علامة عليه باعتباره تراجعًا وإصلاحه كتغيير جذري الآن بدلاً من نشر المزيد من الضرر؟ أسميها _harm_ لأن LambdaJsonSerializer ، الذي يعتمد على System.Text.Json ، لا يحترم السلوك الافتراضي لكيفية تسلسل الخصائص. بالطبع ، استخدام [JsonPropertyName] يصلح الأمر ، لكن مطالبة الجميع بفعل شيء لمواجهة السلوك غير المرغوب فيه يبدو ثقيلًا.

كم عدد الأشخاص الذين سيستمرون في مواجهة هذا كـ _؟!؟!؟ _ لحظة عندما يتبنون LambdaJsonSerializer كمسلسل معياري؟

bjorg في ١٦ أبريل ٢٠٢٠

مرحبًا ، أواجه هذه المشكلة في وظائف الخطوة بعد تبديل مهام lambda إلى .Net 3.1 + المسلسل الجديد. إنه يعيث فوضى لأن الإخراج الآن في علبة الجمل لذا يحاول شكل آلة الحالة التالية تقييم JSON الجديد باستخدام لغة Amazon States ويطرح استثناء Step Function.

هناك حل بديل في الوقت الحالي. من خلال تعيين LAMBDA_NET_SERIALIZER_DEBUG=true في متغير البيئة ، لا يتم تعيين _.options مطلقًا في المسلسل مما يتسبب في إرجاع الحالة دون تغيير. لست متأكدًا مما إذا كان ذلك سيؤدي إلى تداعيات أخرى بخلاف إصدار JSON الإضافي في سجلات Cloudwatch.
https://github.com/aws/aws-lambda-dotnet/blob/master/Libraries/src/Amazon.Lambda.Serialization.SystemTextJson/LambdaJsonSerializer.cs#L69 -L90

IMO ، سيكون من الصعب تزيين جميع عارضاتنا بزخرفة [JsonPropertyName] حيث أن نماذجنا مدفونة في عدد من مكتبات nuget. من الناحية المثالية ، أرغب في أن يعود السلوك الافتراضي إلى PascalCasing الأصلي كما كان من قبل ، لكني على ما يرام باستخدام PascalCaseLambdaJsonSerializer مع lambdas عندما يتم استدعاؤه في مشروع Step Function.

شكر!

panodk في ١٦ أبريل ٢٠٢٠

👍3

أنا متأكد من أن حل كلودجي هو خطأ.

نقطة جيدة في هياكل البيانات المحددة بواسطة التجميعات الأولية.

bjorg في ١٦ أبريل ٢٠٢٠

لا أعرف التأثير الجانبي الذي سيتركه على أشياء أخرى بدون سمات [JsonPropertyName] ، ولكن باستخدام مُنشئ LambdaJsonSerializer الذي يسمح لك بتخصيص مُسلسل JSON يمكن إرجاعه إلى سلوك PascalCase الافتراضي من خلال تعيين JsonSerializerOptions.PropertyNamingPolicy إلى null .

martincostello في ١٦ أبريل ٢٠٢٠

👍1

ربط المشكلة رقم 628 لأنها مرتبطة بهذه المناقشة.

bjorg في ١٨ أبريل ٢٠٢٠

أعتقد أن هذا مرتبط.

بالنظر إلى APIGatewayProxyRequest.cs ، لاحظت عدم وجود تعليقات توضيحية على [JsonPropertyName] . السبب الوحيد وراء نجاح هذا الأمر هو أن أ) LambdaJsonSerializer افتراضيًا لإلغاء التسلسل غير الحساس لحالة الأحرف و ب) يستخدم LambdaJsonSerializer غلاف الجمل على التسلسل.

أستطيع أن أرى كيف أن هذا وفر الكثير من الساعات في التعليق التوضيحي على جميع فئات الطلب / الاستجابة في تجميعات المساعد المختلفة ، لكن هذا يعني أنه عندما نستخدم التجميعات المساعدة ، يتعين علينا استخدام LambdaJsonSerializer في وظائفنا.

بعد فوات الأوان ، أليس من المنطقي وضع التعليق التوضيحي [LambdaSerializer(typeof(Amazon.Lambda.Serialization.Json.JsonSerializer))] في فئة POCO التي يستخدمها معالج الوظيفة بدلاً من فئة الوظيفة نفسها؟ يبدو أنه ، في النهاية ، يجب أن تستخدم الوظيفة المُسلسل المطابق لفئات الطلب / الاستجابة.

bjorg في ١٨ أبريل ٢٠٢٠

bjorg IMO ، POCO هو المكان الخطأ الذي توجد فيه بيانات وصفية للسمات حول التسلسل الذي سيتم استخدامه ؛ يجب أن يهتم POCO فقط بالمجال الخاص به ، أي سمات التحقق من صحة النموذج ونوع / تسمية الملكية ؛ التسلسل يجب أن يحترم / يستخدم هذه التعليقات التوضيحية النموذجية.

IMHO يجب تغيير سمة LambdaSerializer لقبول نوع التسلسل على سبيل المثال. Amazon.Lambda.Serialization.Json.JsonSerializer مع خيارات تسلسل اختيارية ؛ إذا لم يتم توفير الخيار الافتراضي ، فسيتم استخدام الإعدادات المتوافقة.

grahamehorner في ١٨ أبريل ٢٠٢٠

لكن يجب أن يتم شرح POCO بسمات المسلسل الصحيحة: [JsonProperty] لـ Newtonsoft و [JsonPropertyName] لـ System.Text.Json. وبالتالي ، فإن POCO مرتبط بالمسلسل.

bjorg في ١٨ أبريل ٢٠٢٠

يبدو أنه سيتم دعم [DataMember] بواسطة كل من Newtonsoft.Json و System.Text.Json . ومع ذلك ، ليس حتى .NET 5 لهذا الأخير. :(
https://github.com/dotnet/runtime/issues/29975

في غضون ذلك ، قد يكون الحل هو إضافة تعليقات توضيحية إلى جميع نقاط الشراء باستخدام [DataMember] و [JsonPropertyName] . تم تعريف كلتا السمتين في .NET Core 3.1 وبالتالي لا تتطلب تبعيات خارجية إضافية.

ألن يضمن هذا التسلسل / إلغاء التسلسل المتسق لجميع الفئات ، على الأقل لأسماء الخصائص؟ يجب أن يتم تسجيل المحولات من خلال تطبيقات ILambdaSerialize .

bjorg في ١٨ أبريل ٢٠٢٠

القضية المرتبطة هناك مغلقة. ما أفهمه من قراءة هذا الموضوع هو أنهم لا ينوون دعمه: https://github.com/dotnet/runtime/issues/29975#issuecomment -609985802

martincostello في ١٨ أبريل ٢٠٢٠

نعم. أنا أخطأت. رأيت الرابط 5.0 وانتقلت إلى الاستنتاج الخاطئ.

bjorg في ١٨ أبريل ٢٠٢٠

لقد قمت بنشر https://github.com/aws/aws-lambda-dotnet/pull/636 لمعالجة هذه المشكلة. سأكون ممتنًا للتعليقات أو أفضل من تنزيل بنية المعاينة من الرابط الموجود في العلاقات العامة والمساعدة في التحقق من أن التغيير يعمل من أجلك.

normj في ١٩ أبريل ٢٠٢٠

😄1

أولا ، شكرا لمعالجة هذا بسرعة. آسف لأنه خرب يوم السبت الخاص بك.

للوهلة الأولى ، تبدو جيدة. أنا حاليًا بصدد نسخ جميع مراجع Newtonsoft.Json ولست في حالة يمكنني فيها التحقق من الإصلاح ، لسوء الحظ. في الوقت الحالي ، قمت ببساطة بنسخ فئة برنامج التسلسل الإشكالي وإزالة العبارة المسيئة. آمل بحلول موعد التخلص من الذخائر المتفجرة غدًا ، يمكنني اختبار هذا التغيير في فرع التطوير الخاص بي.

أول ما يتبادر إلى الذهن هو احتمال فقدان التعليقات التوضيحية. هل كانت هناك أي هياكل بيانات استجابة لم تستخدم [DataMember] وبدلاً من ذلك اعتمدت على غلاف الجمل الضمني؟

bjorg في ١٩ أبريل ٢٠٢٠

bjorg لا تقلق. بعد أسبوع من الاجتماعات وكتابة المستندات ومساعدة الأطفال في المدرسة ، كان من المريح جدًا قضاء بعض اللحظات الهادئة والقيام ببعض الترميز يوم السبت.

كان لدينا احتمال فقدان التعليق التوضيحي [DataMember] باستخدام برنامج Newtonsoft المتسلسل. لست قلقًا جدًا بشأن ذلك لأنه بالنسبة للأنواع المعروفة لدينا اختبار لذلك. في هذه الحالة ، كانت فجوتي تفتقد إلى اختبارات الاستجابات المخصصة.

normj في ١٩ أبريل ٢٠٢٠

هل يمكن تحرير -rc1 ؟ البديل ، AFAIK ، بالنسبة لي بخلاف ذلك ، اخترق ملفات _.csproj_ مع تمكين ثوابت الترجمة الصحيحة. هل هناك طريقة أخرى؟

bjorg في ٢٠ أبريل ٢٠٢٠

bjorg في العلاقات العامة ، يوجد ارتباط إلى ملف مضغوط يحتوي على حزم NuGet سابقة الإنشاء ، هل يمكنك إعداد مصدر NuGet محلي ووضع الحزم فيه؟

normj في ٢٠ أبريل ٢٠٢٠

تعلمت شيئًا جديدًا اليوم: كيفية الحصول على موجز محلي. تبين أنه سهل للغاية في .NET Core (انظر مقالة SO ).

أكثر ملاحظاتي صلة بالموضوع هي عرض _options Options كخاصية

خلاف ذلك ، كل شيء رائع مع هذا الرمز الجديد من جانبي. شكرا!

bjorg في ٢٠ أبريل ٢٠٢٠

normj إعلامي إذا / عندما تكون هناك حزم nuget محدثة. يسعدني أن أجريها مرة أخرى.

bjorg في ٢٢ أبريل ٢٠٢٠

https://github.com/aws/aws-lambda-dotnet/issues/544#issuecomment -567780775

^ هل بسبب عدم استخدام غلاف الجمل يكسر بوابة API؟

تعمل Cos Pascal بشكل جيد إذا كانت lambda موجودة على ALB ، ولكنها لا تعمل على بوابة API ، وهذا التناقض محير. كيف تم هذا قبل الانتقال إلى system.text؟

phillip-haydon في ٢٣ أبريل ٢٠٢٠

هذا تغيير جذري. الواجهة غير متوافقة. نظرًا لعدم وجود اختبار التكامل و / أو مراجعة مجتمع مرشح الإصدار ، فقد تم تجاوز هذا الانتهاك لمبدأ فصل الواجهة. وكلما طالت فترة بقاء هذا الأمر دون حل ، زادت التكلفة وساعات العمل المهدرة لعملاء AWS ، مما يؤدي إلى تأثير على سمعة AWS.

أوصيك بالانتقال إلى وضع علامة على هذا الإصدار على أنه معطل وعدم تشجيع الترحيل إلى الإصدار 3.1 لجميع المطورين حتى يتم الاتفاق على الإصلاح.
علاوة على ذلك ، أوصي أيضًا بمناقشة أي إصلاح واختباره بالكامل من قبل المجتمع لتقليل احتمالية زيادة تعقيد المشكلة

lukebrowell في ٢٣ أبريل ٢٠٢٠

👍2

lukebrowell تم بالمسلسل للجمهور مع تقديم العلاقات العامة مرة أخرى في يناير. https://github.com/aws/aws-lambda-dotnet/pull/568 قامت العلاقات العامة بإرفاق حزمة تم إنشاؤها مسبقًا للاختبار التي كان من الممكن إجراؤها باستخدام أوقات تشغيل Lambda المخصصة.

نحن نناقش الإصلاح هنا جنبًا إلى جنب مع العلاقات العامة وأرحب بالتعليقات على الإصلاح المقترح https://github.com/aws/aws-lambda-dotnet/pull/636

أوافق على أن هذا تغيير جذري وأنا محبط لحدوثه ولكني لا أوافق على الخطورة التي تقترحها. تؤثر المشكلة فقط على وظائف Lambda التي تعيد الاستجابات المخصصة وليس كل وظائف Lambda و Amazon.Lambda.Serialization. يعمل Json بالطريقة نفسها لذلك لا أعتقد أنه من العدل القول أن إصدار 3.1 Lambda بأكمله معطل. لكنني أتفهم مرة أخرى الإحباط وأنا آسف لأن هذا الخطأ مرت به.

آمل أن أدفع التغييرات في PR في وقت سابق من الأسبوع المقبل ما لم تظهر أي تعليقات مهمة حول التغيير تؤدي إلى تأخير الإصدار.

normj في ٢٣ أبريل ٢٠٢٠

👍2

bjorg تم تحديث PR برابط للمعاينة 2 من الحزم التي تم إنشاؤها مسبقًا. https://normj-packages.s3.us-west-2.amazonaws.com/rework-serialization-preview2.zip

normj في ٢٤ أبريل ٢٠٢٠

👍1

normj أدرك أن المجتمع مسؤول جزئيًا هنا فيما يتعلق نظرك فيما يتعلق بتعليقات lukebrowell وأقترح أن

grahamehorner في ٢٤ أبريل ٢٠٢٠

أود أن أرى مجتمعًا أقوى. لقد كنت أتسكع على موقع awsdevelopers.slack.com ، لكن قناة #dotnet هادئة قليلاً. هل هناك مكان آخر يتجمع فيه أفراد Lambda .NET Core؟

bjorg في ٢٤ أبريل ٢٠٢٠

👍1

bjorg سأشارك ؛) أراك هناك (تقريبًا)

grahamehorner في ٢٤ أبريل ٢٠٢٠

bjorg ممكن الحصول على دعوة؟

phillip-haydon في ٢٤ أبريل ٢٠٢٠

الحصول على رابط دعوة من الوسطاء. سوف نشرها هنا.

bjorg في ٢٤ أبريل ٢٠٢٠

👍1

هل من الممكن إبقاء هذه القضية في الموضوع؟

Kralizek في ٢٤ أبريل ٢٠٢٠

👍3

متفق عليه ، دعونا نبقي هذا على الموضوع. لقد أنشأت مشكلة المجتمع رقم 647 حول كيفية التواصل معي لإضافتك إلى مجموعة سلاك AWS.

bjorg في ٢٤ أبريل ٢٠٢٠

نعم ، أرحب بالاقتراحات حول كيفية إعداد الاتصال المجتمعي بشكل أفضل وأين يمكنني تحسين الاتصال الخاص بي وكيف يمكنني المشاركة بشكل أكبر.

normj في ٢٤ أبريل ٢٠٢٠

_preview2_ تبدو جيدة بالنسبة لي.

bjorg في ٢٦ أبريل ٢٠٢٠

الإصدار 2.0.0 من Amazon.Lambda.Serialization.SystemTextJson انتهى مع التغيير. أهم ما في الأمر هو تحديث فئة المسلسل ليكون DefaultLambdaJsonSerializer .

لقد قمت أيضًا بنشر منشور مدونة يحتوي على قسم يصف التغيير.
https://aws.amazon.com/blogs/developer/one-month-update-to-net-core-3-1-lambda/

normj في ٢٩ أبريل ٢٠٢٠

هل كانت هذه الصفحة مفيدة؟

0 / 5 - 0 التقييمات