Got question is there any plan to support byte[ ] ...
# nebula
w
Got question is there any plan to support byte[] data in nebula? From the graph? The thrift api supports and I was thinking of encrypted values.
w
👍🏻 before considering introducing a new type, will string() + base64 be feasible in such encryption cases?
w
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
Basically I have to throw Unsupported operation, and then will track it down
w
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?
w
Yeah that's pretty close but we also inspect the type and so it would still report string even though it's a byte[]
So again that assumes meta data
w
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.
I created https://github.com/vesoft-inc/nebula/issues/5031 for detailed expectations and others of this new type of support, with core team members being mentioned
w
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.
w
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.
w
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.