Seems like this must only be done with md5 hashes. If a RID or date is send
like this, it will cause an error.
This causes an error to insert into a date field:
params:{"date":"\"2013-01-30 19:24\""}
This causes an error to insert into a LINK field (assuming #9:5 is a valid
record):
params:{"link":"\"#9:5\""}
The following string field works:
params:{"text":"\"Her name was \"Sarah\".\""}
params:{"text":"Her name was \"Sarah\"."}
(both field values are inserted as: Her name was "Sarah")
The following string field works for a md5 hash:
params:{"hash":"\"6ce3ef04cb2cb750d4ce0d0f9648066f\""}
(field value is inserted as: 6ce3ef04cb2cb750d4ce0d0f9648066f)
The following string field works but inserted incorrectly:
params:{"hash":"6ce3ef04cb2cb750d4ce0d0f9648066f"}
(field value is inserted as: 6)
Not sure why there is an inconsistency. Finn has demonstrated the Java API
is working. Not sure if the strict type casting is helping there or not but
sending the params for a prepared query via NodeJS socket and buffers seem
to cause some inconsistencies. Am able to do a regex to catch the md5
scenario and add additional quotes. But not sure if other scenarios exist.
I just want to confirm this is an issue with NodeJS and not with the
OrientDB binary. We are using the Network Binary Protocol. Not sure if
there is another way to check this out.
Thanks!
On Thursday, January 30, 2014 5:15:50 PM UTC-5, Giraldo Rosales wrote:
>
> I can get it working if I try:
> params:{"id":"\"6ce3ef04cb2cb750d4ce0d0f9648066f\""}
>
>
>
> On Thursday, January 30, 2014 4:34:55 PM UTC-5, Giraldo Rosales wrote:
>>
>> Weird. I tried using version 1.6.3 and the latest and both had the same
>> results, both inserting an incorrect value of "6" instead of
>> "6ce3ef04cb2cb750d4ce0d0f9648066f". Is there a way to test this out via a
>> REST call?
>>
>> We are sending the following to the binary call, REQUEST_COMMAND:
>> - operation (bytes) = *41*
>> - session id (int)
>> - mode (bytes) = *s*
>> - class name (string) =
>> *com.orientechnologies.orient.core.sql.OCommandSQL*
>> - sql query (string) = *INSERT INTO V SET id=:id*
>> - params present (boolean) - *true*
>> - params (string) = *params:{"id":"6ce3ef04cb2cb750d4ce0d0f9648066f"}*
>> - composite key params present (boolean) - *false*
>>
>> Is there anything wrong with what is being sent? Not sure how it works in
>> the Java API but not via a socket call in NodeJS.
>>
>>
>>
>>
>>
>> On Thursday, January 30, 2014 10:52:30 AM UTC-5, [email protected] wrote:
>>>
>>> Giraldo Rosales wrote:
>>>>
>>>> Sure.
>>>>
>>>> It works perfectly when placing the value in the SQL directly. Where it
>>>> inserts it incorrectly is when used with a prepared query. So in
>>>> the GratefulDeadConcerts database, try:
>>>> INSERT INTO V SET id=:id
>>>>
>>>> Then add the params:
>>>> {"id":"6ce3ef04cb2cb750d4ce0d0f9648066f"}
>>>>
>>>> Then get the resulting record:
>>>> SELECT * FROM V WHERE id ="6"
>>>>
>>>> You'll get back the incorrect record. Which is why I'm assuming it has
>>>> something to do with the parsing of the prepared query.
>>>>
>>>
>>> When I try with the java driver in 1.6.4, it works:
>>>
>>> ODatabaseDocument db = ODatabaseDocumentPool.global().acquire(
>>> "remote:localhost/test", "admin", "admin");
>>>
>>> Map<String,Object> parms = new HashMap<>();
>>> parms.put("hash", "6ce3ef04cb2cb750d4ce0d0f9648066f");
>>>
>>> Object result = db.command(new OCommandSQL("insert into test set
>>> hash=:hash")).execute(parms);
>>> System.out.println(result);
>>>
>>> And the test class is created with "create class test".
>>>
>>> regards,
>>> Finn
>>>
>>>
--
---
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/groups/opt_out.
