EventId (UUID) serialization to byte array different from one used in EventStore server.

[jezovuk]

In com.github.msemys.esjc.util.UUIDConverter.toBytes() UUID is converter to byte array directly, while .NET Guid does some inversion. See:

• https://docs.microsoft.com/en-us/dotnet/api/system.guid?view=netframework-4.7
• https://stackoverflow.com/questions/45671415/why-does-system-guid-flip-bytes-in-a-byte-array
• https://stackoverflow.com/questions/9195551/why-does-guid-tobytearray-order-the-bytes-the-way-it-does

As a consequence, if eventId is hard-coded to some UUID (read from string) and such event is saved to event store, EventStore will report a different EventId (string) value (consistent with different byte ordering).

As an example, Java UUID 92651dfa-0d83-53e2-a6f7-e6afad26121e will be shown as fa1d6592-830d-e253-a6f7-e6afad26121e in EventStore (when EventId is checked via EventStore HTTP API).

This is mostly problematic in testing/debugging while real-life use is ok as long as UUIDConverter methods for converting UUID to/from byte array are simmetric.

[jboka]

This is mostly problematic in testing/debugging while real-life use is ok as long as UUIDConverter methods for converting UUID to/from byte array are simmetric.

Not if you want to add your own UUID to an event like

EventData event = EventData.newBuilder()
                .eventId(UUID.randomUUID())
                .type("event0")
                .data(new byte[3])
                .metadata(new byte[2])
                .build();

I fixed this with the help of @bremm in #41