This message was deleted.

👍🏻 before considering introducing a new type, will string() + base64 be feasible in such encryption cases?

Yeah we have that in our data models its just not always available.. so sometimes we just want that.. And as I fill out the compatibility layer w/ Neo4j they support it. And so I don’t have access to meta-data from there

Checked with the team that they suggested that we could use the current string as if it’s underlying byte[], will this condition(map byte to string) doable from the adapter layer then?

Yeah that's pretty close but we also inspect the type and so it would still report string even though it's a byte[]

Oh, I thought ugly/blindly treated byte as string is possible in adapter layer, as I dont quite understand it, now I know it’s not possible in some sense/level. We could report this as an issue to include byte prop datatype. But normally this level of change will be made only between major versions, if it brings underlying data changes.

Ok that's a bit of a surprise as everything is stored in byte[] and used as byte[].. so I kind of thought that would be easier to add.

Sorry, that’s my guess on defining it as “breaking” change, I think you are right, it could be more likely a smaller change than I initially thought, let’s see their ideas in the issue.

The major part I saw was you'll need a

base64

function for the DML. As there's no named parameter support. If there was named parameter support it could come from the parameters passed in.