We are currently testing stored procedures with OrientDB.
For performance reasons, we are using java stored procedures with classes
that extends OSQLFunctionAbstract:
*excerpt of client side*:
*... // in 'real world' content is a big serialied object byte[]
contentByte = new byte[] {0,1,2,3} *
*// in 'real world' content is a big serialied object Byte[]
contentClassByte = new Byte[] {0,1,2,3} *
*Object result1 = graph.command("select
myFonction(?)").execute(contentByte);*
*Object result2 = graph.command("select
myFonction(?)").execute(contentClassByte); ...*
*Excerpt of server side:*
*public class MyFunction extends OSQLFunctionAbstract {*
*...
public Object execute( Object iThis, OIdentifiable iCurrentRecord, Object
iCurrentResult, Object iParams, OCommmandContext iContext) {
...
// when the client has transmitted a byte array, iParams[0] type is a
OSQLFilterItemParameter with name ='?' and value='?'
// when the client has transmitted a Byte array, iParams[0] type is a
String with "[0,1,2,3]"
}
*
*}*
It seems that, depending of the caller's parameter type, the server's
parameter type is a OSQLFIlterParameter with unusable value, or a String
representation of the Byte array.
The problem is that this String representation is very inefficient when we
are dealing with large Byte arrays.
So the question is: is there any way to transmit a byte array to a stored
procedure without this cost ? (if we should receive a byte array without
transformation in the server procedure, it will be perfect)
--
---
You received this message because you are subscribed to the Google Groups
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
