Closed newbe36524 closed 2 months ago
Is this one up for grabs?
I really like what this library is doing but am missing this piece and the Mongo BSON conversion.
Happy to contribute!
As a result, I choose to clone source code Vogen and choose
remove fields from Vogen SG code like _value and _init and type them in my source code as below:
[ValueObject<ulong>(conversions: Conversions.SystemTextJson)]
[GenerateSerializer]
[Immutable]
public readonly partial struct UserId
{
[Id(0)] private readonly bool _isInitialized;
[Id(1)] private readonly ulong _value;
private static Validation Validate(ulong input)
{
return Validation.Ok;
}
}
Orleans.Sdk cannot generate serializer code from Vogen SG code, so option 2 & 3 do not work. And option 1 is actually option 4 now.
So the best way I think to integrate Vogen and Orleans like projects, is to support for developer to type fields in their source code instead of generate code in SG. It need some detection to know there is or not self-type fields, if so, do not generate code in Vogen
I think we should rename this issue back to Orleans support rather than the new name?
I think instead of using GenerateSerializer
and exposing the Vogen private fields etc, we should follow the current pattern of Vogen owning the serialization logic. Because Vogen applies many constraints on the ValueObject, we can safely assume that there is one and only one field on the object that needs serialization and can make the value object itself a serializer.
Here's a string example, but you can see this could be compiled to support the other primitive types Vogen supports.
[ValueObject<string>]
[Immutable, RegisterSerializer]
public readonly partial record struct ValueObjectTest : IValueSerializer<ValueObjectTest>, IFieldCodec<ValueObjectTest>
{
[GenerateSerializer]
public readonly record struct Surrogate(string Value);
public void WriteField<TBufferWriter>(ref Writer<TBufferWriter> writer, uint fieldIdDelta, Type expectedType, ValueObjectTest value)
where TBufferWriter : IBufferWriter<byte>
{
StringCodec.WriteField(ref writer, fieldIdDelta, value.Value);
}
public ValueObjectTest ReadValue<TInput>(ref Reader<TInput> reader, Field field)
{
var value = StringCodec.ReadValue(ref reader, field);
return From(value);
}
public void Serialize<TBufferWriter>(ref Writer<TBufferWriter> writer, scoped ref ValueObjectTest value) where TBufferWriter : IBufferWriter<byte>
{
StringCodec.WriteField(ref writer, 0, value.Value);
}
public void Deserialize<TInput>(ref Reader<TInput> reader, scoped ref ValueObjectTest value)
{
var header = reader.ReadFieldHeader();
var stringValue = StringCodec.ReadValue(ref reader, header);
value = From(stringValue);
}
}
I think Vogen could support decorating the value object with RegisterSerializer
and Immutable
attribute and the IValueSerializer
interface along w/ its code get automatically added.
I think we should rename this issue back to Orleans support rather than the new name?
I think instead of using
GenerateSerializer
and exposing the Vogen private fields etc, we should follow the current pattern of Vogen owning the serialization logic. Because Vogen applies many constraints on the ValueObject, we can safely assume that there is one and only one field on the object that needs serialization and can make the value object itself a serializer.Here's a string example, but you can see this could be compiled to support the other primitive types Vogen supports.
[ValueObject<string>] [Immutable, RegisterSerializer] public readonly partial record struct ValueObjectTest : IValueSerializer<ValueObjectTest>, IFieldCodec<ValueObjectTest> { [GenerateSerializer] public readonly record struct Surrogate(string Value); public void WriteField<TBufferWriter>(ref Writer<TBufferWriter> writer, uint fieldIdDelta, Type expectedType, ValueObjectTest value) where TBufferWriter : IBufferWriter<byte> { StringCodec.WriteField(ref writer, fieldIdDelta, value.Value); } public ValueObjectTest ReadValue<TInput>(ref Reader<TInput> reader, Field field) { var value = StringCodec.ReadValue(ref reader, field); return From(value); } public void Serialize<TBufferWriter>(ref Writer<TBufferWriter> writer, scoped ref ValueObjectTest value) where TBufferWriter : IBufferWriter<byte> { StringCodec.WriteField(ref writer, 0, value.Value); } public void Deserialize<TInput>(ref Reader<TInput> reader, scoped ref ValueObjectTest value) { var header = reader.ReadFieldHeader(); var stringValue = StringCodec.ReadValue(ref reader, header); value = From(stringValue); } }
I think Vogen could support decorating the value object with
RegisterSerializer
andImmutable
attribute and theIValueSerializer
interface along w/ its code get automatically added.
It sounds like we have two separate issues to track here then:
[RegisterSerializer]
above to generate IValueSerializer
(for structs) and IFieldCodec
implementations Strictly for the Orleans use case, I prefer option 2, it results in cleaner, less duplicative code that doesn't "know" the internals of the ValueObject.
Also, I can take this one on!
Hi - sorry for the delay in replying. Very happy to accept any contributions. It would be great to enable everyone to use Vogen in Orleans while still having all of the current constraints that ensure safety.
go to: https://github.com/SteveDunn/Vogen/issues/385#issuecomment-1534020797
Describe the feature
Support to be serialize with Microsoft/orleans
see: https://github.com/dotnet/orleans/issues/8374
Option 1
Support to declare custom constructor, then GenerateSerializer can works well in orleans.
Option 2
if
then generate
Option 3
surrogates-for-serializing-foreign-types <https://learn.microsoft.com/en-us/dotnet/orleans/host/configuration-guide/serialization?pivots=orleans-7-0#surrogates-for-serializing-foreign-types >
if
then generate