You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can probably use the switch from Ecto the JSON RPC schema validation to simplify the migration, as it might be complex to use either Hex for legacy REST API and type of the JSON RPC API.
We can probably use the switch from Ecto the JSON RPC schema validation to simplify the migration, as it might be complex to use either Hex for legacy REST API and type of the JSON RPC API.
Since we planned to use OpenRPC standard #1220
I think we could temporarily add a flag in Ecto has it will be deleted soon with OpenRPC implementation
We can probably use the switch from Ecto the JSON RPC schema validation to simplify the migration, as it might be complex to use either Hex for legacy REST API and type of the JSON RPC API.
Since we planned to use OpenRPC standard #1220 I think we could temporarily add a flag in Ecto has it will be deleted soon with OpenRPC implementation
I think it might require another type in Ecto.Schema instead of Hex, to support both.
Is your feature request related to a problem?
When using the REST API, we'd have to base16 the transaction.content. This was a legacy decision.
Describe the solution you'd like
Now that we have a new API we can remove that legacy
Additional context
No response
Epic
No response
The text was updated successfully, but these errors were encountered: